What's the purpose of 'xf_user_group_change'?

[AlexT]

I understand you can change someone's secondary usergroup by directly accessing the datawriter like this:

$userDw = XenForo_DataWriter::create('XenForo_DataWriter_User');
$userDw->setExistingData($visitor['user_id']);
if ($userDw->get('secondary_group_ids'))
{
  $existingGroups = array_fill_keys(explode(',', $userDw->get('secondary_group_ids')), true);
}
else
{
  $existingGroups = array();
}

$existingGroups[self::NEW_GROUP_ID] = true; // the new group

$userDw->setSecondaryGroups(array_keys($existingGroups));

$userDw->save();

What I don't understand yet is how xF uses the xf_user_group_change, specifically when changing someone's secondary usergroup through the addUserGroupChange/removeUserGroupChange user model methods. How is that different from using the datawriter as outlined above? Any ideas?

 

[tyteen4a03]

It's a bookkeeping system so that user group changes don't overlap each other. For example, if you set somebody's user group in the AdminCP, then the user buys a paid user upgrade, when you decide to remove the admin-set user group it doesn't remove the user upgrade user group as well.

Check out Waindigo's Joinable User Group addon (I'm still waiting for him to push my refactored version) to get a grasp how it works.

 

[AlexT]

Thanks for the excellent explanation, tyteen.

I did look at Waindigo's add-on, and I noticed that he was using addUserGroupChange/removeUserGroupChange for the group joins.

Using your example and assuming a user was added to a secondary usergroup through addUserGroupChange(). If I remove that secondary usergroup from the user's settings in the admin CP, then am I right in understanding that, even though the group is no longer ticked in the settings, the user still has the inherent permissions of that secondary usergroup - for as long as the latter isn't removed again through removeUserGroupChange()?

 

[tyteen4a03]

Thanks for the excellent explanation, tyteen.

I did look at Waindigo's add-on, and I noticed that he was using addUserGroupChange/removeUserGroupChange for the group joins.

Using your example and assuming a user was added to a secondary usergroup through addUserGroupChange(). If I remove that secondary usergroup from the user's settings in the admin CP, then am I right in understanding that, even though the group is no longer ticked in the settings, the user still has the inherent permissions of that secondary usergroup - for as long as the latter isn't removed again through removeUserGroupChange()?

Edit: see Mike's comment

 

[Mike]

Yes. (Given that you didn't insert the change using the id "admin", that is )

No, that's incorrect. The selected groups in the admin always reflect the permissions. You are correct that it's a book keeping system though.

 

[AlexT]

Hm, thanks. I am still trying to wrap my head around when this book keeping comes into play, and when it is preferred over using the datawriter directly to change a user's secondary usergroups.

For example, I wrote a small add-on allowing members to join (or leave) a specific secondary usergroup through their User CP (I didn't use Waindigo's add-on because it wanted to keep the code small and his add-on seems to do much more than what I would need). I implemented this usergroup change through the datawriter routine posted above, which seems to work just fine. Is there a design pattern when addUserGroupChange/removeUserGroupChange is the preferred way of doing it? Or are these methods always the preferred way?

 

[tyteen4a03]

Hm, thanks. I am still trying to wrap my head around when this book keeping comes into play, and when it is preferred over using the datawriter directly to change a user's secondary usergroups.

For example, I wrote a small add-on allowing members to join (or leave) a specific secondary usergroup through their User CP (I didn't use Waindigo's add-on because it wanted to keep the code small and his add-on seems to do much more than what I would need). I implemented this usergroup change through the datawriter routine posted above, which seems to work just fine. Is there a design pattern when addUserGroupChange/removeUserGroupChange is the preferred way of doing it? Or are these methods always the preferred way?

Are you sure you're going to say no to this?


But back on topic: Yes, I think so. (or it's just me who can't think up of a case to directly use the DW)

 

[Mike]

I'll just throw this out and the reasoning for the system begins to make sense.

You have 3 user upgrades and (for some reason) they all add group X. The upgrades last 1 day, 1 week, and 1 month respectively. A user buys all 3 simultaneously. After the 1 day upgrade expires, they should not be removed from group X because the other upgrades keep them there. Same after 1 week, but after 1 month, they should be removed.

 

[AlexT]

Are you sure you're going to say no to this?

Heh, very nice! My implementation is a very very basic...



If I need more features and/or the moderation functionality, I'd seriously consider the Waindigo add-on. Meanwhile I am hoping that joinable usergroups become a xF core feature one day...

 

[AlexT]

You have 3 user upgrades and (for some reason) they all add group X.

This makes a lot of sense now. Thanks!