Partial fix Warnings - Warning Actions not occuring in specific circumstances

[Harpers Tate]

Setup:
Suppose that we have a Warning Action such that 10 points adds a user to a Restricted (secondary) UserGroup for one month.

Scenario:
A user is warned totalling 10 points. The system then performs the action and adds the user to the Restricted Group.

Suppose a review takes place and it is decided that the warning was issued incorrectly. So the warning(s) is/are either deleted or force-expired. And the AdminCP is used to remove the user from the Restricted UserGroup (because the adjustment to the Warning won't have any effect).

The user is thus back to original state - no (or insufficient) points and no secondary UserGroup restriction in place.

Suppose then that still during the intial one month period, the same user is warned again and accrues 10 points.

What should happen is that they should be added to the secondary group for a month.

What DOES happen is.....nothing. The warning is listed and the points are present, but the ACTION is not triggered.

(For completeness, if the second warning occurs OUTSIDE that initial one month, then the action occurs correctly).

It's as if the presence of an incomplete pending action misleads the system; whereas what it should be doing is looking at the TRUE state of the user.

 

[Mike]

This is unlikely to change (at least in the short term) for technical reasons mostly. The situation is potentially ambiguous.

The situation is that once a user reaches a threshold, the action is applied for a specified period of time and the fact that this user is added to a group is logged. Them dropping below that threshold does not remove the warning action. (The action is applied for a specific time - what to do through natural expiration, "unnatural" expiration, and deletion is probably the crux of the issue.)

As the action is still applied, removing them from the group manually removes the group but the action is still applied. When it gets applied again, the automated changes system sees that it expects the user to already be in the group and does not add it again. Essentially, it allows a manual removal to override it.

This applies to all systems that programmatically add user groups (it's the "user group change" system).

 

[Harpers Tate]

I see. So the Automated Changes system is assuming its own data is correct, rather than testing the true status of the user to determine the need or otherwise for the action.

What would be the effect of simply ignoring this test
"the action is still applied. When it gets applied again, the automated changes system sees that it expects the user to already be in the group and does not add it again"
in other words, the system always attempts to apply the Add Usergroup change again.

In a NORMAL case (user is still in the additional usergroup) then trying to apply the ADD again would have what effect? (Guesses at none - or could be so coded as to be wholly benign?).
In my SPECIFIC case (user is not in the additional usergroup - has been manually edited) then trying to apply it (again) will have the required effect.

 

[Stuart Wright]

@Harpers Tate how often does this scenario happen on AVForums? Is it particularly frequent? Just trying to give Mike an idea of how much of an issue it is.

 

[Harpers Tate]

Well the initial scenario - warning issued but then the action altered in some way - probably occurs a couple of times a month. I'd guess that the subsequent issue where another Warning is issued during the unelapsed period is pretty rare - but likewise we may not actually know when the fault described here has been triggered. Guess - twice a year at most.

 

[Harpers Tate]

The situation is that once a user reaches a threshold, the action is applied for a specified period of time.....

Is there any way (or, if not, should there be) to interrogate and/or amend these pending actions?

 

[Xon]

Is there any way (or, if not, should there be) to interrogate and/or amend these pending actions?

There doesn't appear to be any UI to see the under-the-hood user group changes and any expiry times as they are not the full User Group Promotions.

 

[Jon W]

I have released an add-on here that allows for moderators to enquire and modify the expiry date of temporary user changes from the front-end:
http://xenforo.com/community/resources/temporary-user-changes-by-waindigo.3361/

 

[Mike]

1.4 has a change to this system with respect to warnings at least.

If you delete a warning and cross a threshold, we attempt to undo the effects of that threshold. This is essentially saying that the warning was incorrect. Note that there are some changes to the core here so this won't be able to be done for actions that were applied before running 1.4.

Conversely, if you expire a warning (either explicitly or let it naturally happen), time-based actions stay (if they didn't, that would actually break them; it'd just be a points threshold). In the case of an explicit expiration, it's roughly suggesting that the warning was valid but there's a special reason to remove the points.

 

[Harpers Tate]

Every little step is a help.

However, with respect, the underlying issue here is that
When a NEW warning action is requested (by the issue of a new Warning), the system is determining whether or not to attempt to apply the Warning Action by looking at other Warning Actions pending. Whereas what it should be doing is looking at the true status of the user.

I mean - regardless of whether the Actions System thinks a User should be (eg) in a secondary user group - either they actually are or they actually aren't. It is that data that should be being interrogated, I reckon.

So I wouldn't describe this as fixed.

I must be missing something but I'm just not getting why this system has to use its own internal (and possibly wrong or at best misleading) data here.

 

[Harpers Tate]

I found something else out yesterday, thanks to @Waindigo 's add-on (see post #8 above).

Scenario:
We have Warning Actions specified thus:
- at 6 points, add user to restricted usergroup for one week
- at 10 points, add user to restricted usergroup for one month
- at 18 points, add user to restricted usergroup for one month (yes, it's the same as 10)
- at 30 points, add user to restricted usergroup permanently.

We gave a user 30 points (in one Warning) to restrict them permanently.

The system created all FOUR of the temporary actions above; one to expire in a week, two to expire in a month, and one permanent.
I would have thought that a well-implemented system would contain de-duplication logic here.

 

[Mike]

They're not duplicates. If you remove 3 of the 4 of them, they should still be in the group. The system you're looking at is used by warning actions but it has nothing to do with warning actions itself.

As noted, this isn't tagged as a full fix - it is a partial change to handle the specific case covered in the initial message.

I have explained how the user group system works and there are logical reasons behind it, and changing it to work how you desire would break those behaviors and underlying assumptions. As such, it's not something that I would change in the short term (it would be a v2-level of a change, I think).