Hi there, I am running into an issue using the new Member listener. When updating a members groups, and using the onProfileUpdate callback, the member object does not reflect the latest changes and its always one iteration behind. The $changes array has the correct updates. Even when calling a load to attempt to get the latest DB results, it it still one iteration behind. The DB updates correctly,

To reproduce:

1. Update a members secondary groups
2. Log the $changes array, $member->groups and MemberClass::load($member->member_id)->groups. 
3. The results in the $changes array will not be the same as $member->groups. It will be the results of your previous save.

Edited October 18, 2024Oct 18 by mountaininteractive

19 hours ago, mountaininteractive said:

Hi there, I am running into an issue using the new Member listener. When updating a members groups, and using the onProfileUpdate callback, the member object does not reflect the latest changes and its always one iteration behind. The $changes array has the correct updates. Even when calling a load to attempt to get the latest DB results, it it still one iteration behind. The DB updates correctly,

To reproduce:

1. Update a members secondary groups
2. Log the $changes array, $member->groups and MemberClass::load($member->member_id)->groups. 
3. The results in the $changes array will not be the same as $member->groups. It will be the results of your previous save.

You say "listener", does that mean v5?

Correct, on V5.

In that case, this is the correct behavior.

The onProfileUpdate event is triggered before the object is updated, which is intentional. Use the $changes array to see the latest data.

9 hours ago, Esther E. said:

In that case, this is the correct behavior.

The onProfileUpdate event is triggered before the object is updated, which is intentional. Use the $changes array to see the latest data.

Help me understand that. On line 543 of Member.php, the model is persisted to the DB. Not until line 562 is the event fired. 

You're correct, I misspoke.

Can you clarify - is this only with the member group, or do you see this with other changes as well?

I have only been using that one method and only checking for group changes. It appears to me that the user object is not being rehydrated with the most recent data after the DB transaction. It is always one step behind. Within the listener method, the $member object reflects the most recent object state - not the updated state. Once the request finishes, and you fetch a user (Member::loggedIn() or Member::load(...)) then the user reflects the most current state.

Edited October 23, 2024Oct 23 by mountaininteractive
updated response

Can you please post this on our Bug tracker? Thanks.