change role on status change

  • Resolved IT Hertz

    (@it-hertz)


    2 years, 7 months ago

    Since UM’s various restrictions and so forth are based on roles rather than status, I need to change a user’s role upon status change (e.g., immediately after being approved for membership).
    I tried this:

    add_action( 'um_after_user_is_approved', 'set_role_upon_approval', 10, 1 );
function set_role_upon_approval( $user_id ) {
   um_fetch_user ( $user_id );
   UM()->roles()->set_role( um_user, 'um_newrole' );
// also tried UM()->roles()->set_role( um_user, 'New Role' ); just in case it wasn't keying on the actual slug
}

    It does nothing. No errors and no effect. Role remains unchanged.
    I also tried this in the add_action function, from your docs:

    global $ultimatemember;
um_fetch_user( $user_id );
$ultimatemember->user->set_role( 'um_newrole' );

    That results in a site critical error.
    I also tried it direct:

    $user_id->set_role('um_newrole');
// also tried $user_id->set_role('newrole'); after creating a non-UM role slug

    Nothing works! I didn’t find a different hook that looked more appropriate, but is there one? What am I doing wrong?

Viewing 6 replies - 1 through 6 (of 6 total)

  • @it-hertz

    Try to add UM()->user()->remove_cache( $user_id ); after changing the role.

    Thread Starter IT Hertz

    (@it-hertz)

    Turns out it works with UM()->roles()->set_role( $user_id, 'um_newrole' ); it being the sole line in the function. No need to fetch the user separately after all. UM might want to update their docs accordingly, as they suggest um_fetch_user must necessarily be used.

    Btw, I just added your cache handler. It did not fix the issue when um_user is used instead of $user_id.

    Thread Starter IT Hertz

    (@it-hertz)

    Actually, as I need to allow for demoting roles as well as promoting, I did this instead:

    add_action( 'um_after_user_status_is_changed_hook', 'um_change_status', 10, 1 );
function um_change_status( $user_id ) {
   $stat = get_user_meta( $user_id, 'account_status', true );
   if ( $stat == 'awaiting_admin_review' ) {
      UM()->roles()->set_role( $user_id, 'um_pending' );
   }
   elseif ( $stat == 'approved' ) {
      UM()->roles()->set_role( $user_id, 'um_approved' );
   }
}
    Plugin Support Ultimate Member Support

    (@ultimatemembersupport)

    Hi @it-hertz

    Sorry for the late response. Thanks for letting us know how you’ve resolved the issue. We will update the doc related to this customization. Thanks again.

    Hi @it-hertz ,

    I would appreciate it if you could tell me which documents you are referring to? So we can check and update it, Thank you!

    Thread Starter IT Hertz

    (@it-hertz)

    It’s been a while, so I’m trying to remember exactly what happened. After searching again just now, I think I must have been referring to this: um_user
    A user must be previously set using um_fetch_user() to properly retrieve user data.
    “must be”

    And: um_fetch_user
    This function sets a user and allows you to retrieve any information for the retrieved user
    “allows you to”

    And: change community role
    To change the community role of a specific user, you have to know the user ID first.

    These all conspire to form a clear implication that in order to know the user ID, one must employ um_fetch_user, even when not in a loop and when no value would be returned.

    IIRC, this reinforced that idea in my mind at the time: um_after_user_status_is_changed_hook
    being implied by the absence of an argument, specifically $user_id, and callback count in the example on that page. It suggests that $user_id is not to be used and that this hook actually has no callback arguments, which is apparently wrong.
    I realize the default accepted arg count is 1 when no number is specified, but with the missing $user_id it still briefly threw me off. Then again, maybe it works with no arg spec’d, I don’t recall whether I tried that.

    All of those things led me to believe my attempts were failing because um_fetch_user must be used and that I was just using it improperly, when in actuality I was redundantly calling for $user_id with the superfluous fetch. If that makes sense.

    My final snippet works, which demonstrates that um_fetch_user is not needed in all cases, even though this is implied across multiple areas of the docs.

    Thank you for your consideration.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘change role on status change’ is closed to new replies.