Not planned Promotion Ladder: Stop promotions from flipping back and forth

[Alpha1]

Promotions do not have a natural sequence in the sense that you cant setup a ladder where a user goes up or down the ladder. The only order that promotions have is defined by the sequence of creation of the promotion. There is no function to remove a user from a user group.
This becomes especially problematic when you have a complex ladder with sin-bin usergroup. The result is that users are promoted, demoted back and forth eternally.

To resolve this there would need to be a promotion ladder where we can set the order of our usergroup promotions. And a user group promotion setting to remove a user from a usergroup.

 

[Floyd R Turbo]

Another good one. I actually need this for something I was trying to do to work-around not having the ability to "self-deactivate" and "re-activate" a user account

 

[Mike]

If a user is flipping back and forth, that would generally indicate an issue with your promotion configuration. It would indicate you've defined a setup where A is true when B is not true and B is true when A is not true.

First, I'll say that there almost certainly won't be a promotion that removes a user from a group. There was a previous suggestion regarding this, but that concept simply doesn't make sense. If one action says a user should be in a group and another says it shouldn't, the result would be undefined unless you make a particular rule that defines a priority, but then you actually need more than two levels to be able to define things with some level of granularity.

Regardless, you don't need the a promotion that removes a user from a group; you would define extra criteria that would cause the promotion to no longer match. You give the example of a sin bin group. I wouldn't recommend this approach if possible (see below), but you could simply define your promotions to require the users to not be a member of the sin bin group.

Further, you can define a ladder of promotions using a similar approach, though again this wouldn't follow our recommended approach as it would require duplicating permissions between groups, unless you really do have distinct sets of permissions (that aren't super sets). If you want to define A -> B -> C, then A requires the member to not be a member of group B or C and B requires them to not be a member of group C.

Regarding the approach of removing the promotions with the sin bin group: if you're removing permissions, you should be doing this through the sin bin group itself. Promotions are not designed to be instantaneously applied. They are only checked periodically when users are active. Therefore, you should be removing the permissions via the sin bin role (as that is what it is designed to do), rather than relying on a subsequent demotion.

Based on my understanding of your request, what you want to do is already possible, but I'm going to tag this as "not planned" since you're referring to other changes which would introduce other difficulties/ambiguities.

 

[Alpha1]

If you want to define A -> B -> C, then A requires the member to not be a member of group B or C and B requires them to not be a member of group C.

I am not sure if you intended your example to go one way (up) as I need promotions to go two ways. I want not only promotion but demotion as well. (down)
Which seems to be exactly why the 'not be a member of group X' approach fails. How do you let B go to A?

Then consider this:

usergroup A
usergroup B: Demote to A based on criteria 1,2,3. Promote to B based upon criteria 4,5,6.
usergroup C: Demote to B based on criteria 7,8,9. Promote to C based upon criteria 10.
usergroup D: Demote to C based on criteria 11. Promote to D based upon criteria 13.

Users start at usergroup B, as A is the sin-bin group.

Regarding the approach of removing the promotions with the sin bin group: if you're removing permissions, you should be doing this through the sin bin group itself. Promotions are not designed to be instantaneously applied. They are only checked periodically when users are active.

Its no problem if demotions to the sin-bin group or any other demotion only happens if the member is online, as thats the only time the member will be able to use their permissions. I dont see a problem with some delay either. But do you mean that a user promotion may be executed while the member has been active for a long time?

 

[Mike]

Promotions are two way: the lack of matching criteria is a demotion. When someone no longer matches B, they would get A (though there may be a delay as you're roughly depending on some order of operations here).

I'm not exactly following your example ladder. You're showing different criteria for promotion and demotion (to the same group), so the only thing that's coming into my head is some sort of "hysteresis effect" with promotions (as in, match at >= 10 posts, but once matched, match while >= 5 posts instead). That really sounds like a whole different suggestion though, so maybe I'm misinterpretting.

Again though, I would note that XF is designed around what would be considered "roles" (which is what user groups basically are). Roles can either add or remove permissions. You can use a promotion to add people to a sin bin group and still remove permissions through that without touching any other promotions. Similarly, if you intend to go A->B->C, then presumably C gets all of the permission changes of A and B, so if you don't force removal of A and B, then you only need to define the changes in the C role specifically.

But do you mean that a user promotion may be executed while the member has been active for a long time?

A user may be active (and browsing/posting) for a period of time before a promotion check is triggered again. We do attempt to run promotions when a user first becomes active, but a user already may be active and their criteria changes. I was presuming that the sin bin group would be added through things like warning actions, so I was noting that you should explicitly remove the permissions you don't want people to have via the sin bin group rather than relying on a full hierarchy change (which, as noted above, isn't explicitly needed in the system, though clearly you may have personal preferences).

 

[Alpha1]

the lack of matching criteria is a demotion.

For xenforo it works that way technically. And thats the point of this thread. Because in most cases in reality a demotion is not a reverse promotion when it comes to criteria. Promotions are generally done for positive criteria, while demotions are generally done for negative criteria.

For example: If you hire a worker you may promise a promotion if he reaches a certain accomplishment. But to demote him again after that promotion its not normal to do so for the absence of the accomplishments already reached. A demotion is applied if the employee performs abominable. The same goes for forums. You promote for positive criteria and you demote for negative criteria.
For example:
Promotion from A to B. IF criteria 100 posts AND 20 trophy points are true.
Once a member reaches this promotion the criteria will always be true.

Demotion from B to A. IF criteria -100 negative post ratings is true.
So now we have a promotion and a demotion for which both the criteria are true.
XenForo will then promote and demote ad infinitum. i.e. flip back and forth.

This is why I mentioned different criteria for promotion and demotion on purpose.
Its possible to factor in the absence of negative criteria into the promotion, but this becomes problematic and a pain to do. Because then you can end up in a situation where promotions conflict.

Also consider that promotions and demotions are not only from A to B to C or the other way around. There is good reason to also do:
A to C
C to A

And have multiple promotions following the same path. For example:
C to B for criteria 1
C to B for criteria 2

i.e. demote from C to B IF criteria 1 OR 2 are true.