Callback 'user.change_group' is trigger happy

gomedia · 2021-07-26 23:29:11

According to the documentation, the callback user.change_group > done should fire:

After privileges of an existing user account has been successfully altered.

I’m seeing it triggered whenever the user panel is “saved”, regardless of whether the role/group is changed or not.

When no changes to the user are made the data returned contains the original group, so the documentation assertion:

An array containing a list of the user names affected and new privilege level they have been assigned

… is incorrect.

Am I reading this wrong or is there a bug?

Is there another way that a notification of the actual group change can be triggered?

Bloke · 2021-07-29 13:59:52

Sorry, could have sworn I replied to this.

Reading the code, I can’t see why this callback would fire (raised in change_user_group()) unless the multi-edit is used. But maybe changing the callback system to give plugins more freedom to register their own handlers has an unintended side-effect.

Will investigate, thanks for the report.

gomedia · 2021-07-29 21:59:50

Bloke wrote #331167:

Sorry, could have sworn I replied to this.

No problem.

change_user_group() needs to fire when an individual user is edited, because the user’s group can be changed at that point (among other things). However, I’m not sure if the code is taking a “before” picture of the user’s level when deciding to trigger the “group has changed” callback.

Bloke · 2021-07-30 08:31:52

gomedia wrote #331171:

change_user_group() needs to fire when an individual user is edited, because the user’s group can be changed at that point (among other things).

Ah *penny drops* This is from the User Edit panel. Yes, in that case that function will likely be called and the callback is therefore in the wrong place. It should only fire inside the ‘success’ conditional rather than presuming the function is only called from a multi-edit scenario, where it’s only initiated if the privilege is altered. This might actually be the case for other ‘success’ callbacks – we should check.

Alternatively, we could do a comparison in the author save routine that checks if the role has changed and doesn’t call the library function at all if there’s no difference.

That’s an easy fix either way I think.

Last edited by Bloke (2021-07-30 08:32:31)

gomedia · 2021-07-30 11:38:27

Bloke wrote #331174:

… l rather than presuming the function is only called from a multi-edit scenario, where it’s only initiated if the privilege is altered.

Unfortunately it’s the same problem on multiedit panel as well. Selecting a user and setting the priv level (i.e. role) to the same value causes the callback to erupt. So it’s firing on “Change role action selected” as opposed to “Role has been changed”.

Textpattern CMS

Textpattern CMS support forum

#1 2021-07-26 23:29:11