Removing a user from a group with a Trust Level effect does not recompute the users Automatic Group memberships

[elmstedt (Jake Elmstedt)]

I’ve read the topic, Group trust level where it is said,

@JammyDodger

When you remove someone from a group that grants a trust level it recalculates their trust level and sets it to what it would be without the group bump.

The trust levels are adjusted on both group add and group remove.

As well as this older topic, Should losing group membership unlock trust level?

Where the situation described largely meets with my experience,

@Falco

However it’s very tricky, because for example:

1. User is TL1
2. User get into Patreon, patron group has been configured to give TL3 in this site
3. User exits Patreon, plugin removes from group
4. User still TL3 because trust level is locked automatically.
5. Admin unlocks trust level, user becomes TL2. (Not TL1, you can’t get demoted from TL2 without locked TL).

But, what I have found in my own testing instance of Discourse is this…

With all Trust Level settings at default, I have a TL1 account (U) and a group named tl3 which grants Trust_Level_3.

1. Starting conditions
   • Trust Level: 1: basic user Unlocked
   • Automatic Groups: trust_level_0, trust_level_1
   • Custom Groups: None
2. Add U to tl3
   • Trust Level: 3: Regular Unlocked
   • Automatic Groups: trust_level_0, trust_level_1, trust_level_2, trust_level_3
   • Custom Groups: tl3
3. Remove U from tl3
   • Trust Level: 2: Member Unlocked
   • Automatic Groups: trust_level_0, trust_level_1, trust_level_2, trust_level_3
   • Custom Groups: None
   • NOTE: Despite having a trust level of 2, the user is still in the automatic group trust_level_3. With the understanding a user cannot be demoted to TL1 without a locked trust level, the expected outcome here is the user should immediately lose membership in the trust_level_2 automatic group.
4. Lock U’s trust level
   • Trust Level: 2: Member Locked
   • Automatic Groups: trust_level_0, trust_level_1, trust_level_2, trust_level_3
   • Custom Groups: None
   • NOTE: Despite having a Trust Level of 2: Member, the user is still in the automatic group trust_level_3.
5. Unock U’s trust level
   • Trust Level: 1: Basic Unlocked
   • Automatic Groups: trust_level_0, trust_level_1
   • Custom Groups: None

So, when unenrolling a user from a group the Trust Level is recalculated automatically and instantly, but the automatic group membership is not recalculated unless the user’s trust level experiences an unlock event.

My assumption is that automatic group memberships are computed systemwide for all users once per day and the automatic group memberships will be rectified at that point. But it feels as though automatic group memberships should be either triggered upon removal from a group with a trust level effect or triggered immediately upon any change in trust level, not just on an increase of trust level.

So the backend API call to,

POST {{site}}/admin/users/{{userId}}/groups

updates the automatic group memberships, but

DELETE {{site}}/admin/users/{{usedId}}/groups/{{groupId}}

does not, which feels like a bug, especially if you are using automatic trust level groups for access control.

And, for completeness, obviously calls to,

PUT {{site}}/admin/users/{{userId}}/trust_level

which are invoked when manually changing a user’s trust level in the admin interface, immediately recompute the automatic group memberships as expected.

[sam (Sam Saffron)]

@elmstedt

My assumption is that automatic group memberships are computed systemwide for all users once per day and the automatic group memberships will be rectified at that point. But it feels as though automatic group memberships should be either triggered upon removal from a group with a trust level effect or triggered immediately upon any change in trust level, not just on an increase of trust level.

Yeah, the fundamental dev xp thing here is that we should be disallowing this fiddling with automatic groups and force you down the route of using PUT {{site}}/admin/users/{{userId}}/trust_level only to transition stuff. Return a 422 or something if people attempt to use endpoints to manually add people to the groups or remove.

Unrolling trust level should always happen from here:

Cause that also support lock which is critical.

[elmstedt (Jake Elmstedt)]

I get that.

I just want to be clear, all the API stuff was just seen recording the XHR stream when performing actions on group memberships through the group membership UI. I’m not actually performing these as API calls, they’re just the API calls being made when using the UI.

So, my thinking is that if there is a group with a TL3 effect, clicking this button,

Should immediately remove them from the trust_level_3 group if they do not otherwise meet the requirements for Trust Level 3 or have that trust level locked.

The imagined use case here is too allow, say a group of TL4 users to be set as owners of a group with a TL3 effect so they could manually promote people to TL3.

The promotion aspect works, but those same users removing someone from the TL3 effect group does not have the immediate effect of removing the affected user from trust_level_3.

Fully understanding this is very much an off-label use of the feature.

It just seems incongruous that a user could have a their Trust Level changed from 3 to 2 and remain in the trust_level_3 group until the next recalculation event.