change role on status change

Resolved IT Hertz
(@it-hertz)

3 years, 10 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)

missveronica
(@missveronicatv)

3 years, 10 months ago

@it-hertz

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

Thread Starter IT Hertz
(@it-hertz)

3 years, 10 months ago

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)

3 years, 10 months ago
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)

3 years, 10 months ago

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.

gelieys
(@gelieys)

3 years, 10 months ago

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)

3 years, 10 months ago

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.