As I have said elsewhere and TTO mentions, this was intentional as we don't
want users w/o the ability to revoke user groups to circunvent that
restriction setting the expiry to 1 sec. Thanks.

cf. T156784

@MarcoAurelio May I ask you to re-read the task description? What you're talking about is not what this task is about. This is about giving users who already are able to remove rights but not to add rights the additional possibility to shorten the expiry, but not extending it. So everybody who can say "Remove User X from group Y now" will be able to say "Remove User X from group Y at time Z" (with Z needing to be smaller than what is set as an expiry right now). A user who can't revoke permissions won't be given those rights of course. So this is the very equivalent to what was introduced in T156784.

I do not know in which strange scenario a user will be able to remove a
right that cannot add themselves. If there's any, please share. Thank you.

On the other hand, those who can remove a right but not add it will not gain any additional powers.

Well implementing this won't change anything about "powers". I can achieve the very same thing requested by this task by writing a bot to log into a user account and remove user rights from another user at a given time. Just to point out that this doesn't add any new power.

As far as I can see, there are no groups on the WMF cluster with such permissions, and I see this as a purely hypothetical situation.

This may be true or not, I really don't know. I tend to trust you on this. We do have "remove from self", but it'd be very few users who would use user rights expiry in that context I'd guess.

To be honest, I didn't really look into who might have had a usecase for this somewhere sometime, but I stumbled across this when looking into T157587 and was quite curious why you would be required to have the right "add X to group Y" to be able to decrease the expiration time - that's extremely counter-intuitive and I don't see much of a reason for it, because as explained above, giving this to everybody who can remove rights doesn't give extra power. For intuitiveness I'd expect to have both the feature to increase, but not decrease for users who can add, but not remove and the feature to decrease, but not increase for users who can remove, but not add. That it is the way it is now is something I'd never expect when setting up user permissions for a wiki, so it felt sane to me to propose alignment of the behaviour of for a "can remove, but not add" user with the behaviour for a "can add, but not remove" user."

I do not know in which strange scenario a user will be able to remove a right that cannot add themselves.

Why do we have "or vice versa" in "A * indicates that you cannot remove the group once you have added it, or vice versa." then (not talking about the message, but the technology implementing this)? Because we don't really have a reason to not let someone who wants to configure their wiki this way do it. I'm not up for inventing any use cases here, in fact, I agree that use cases might be rare and that this is indeed "Low(est)" priority. I didn't expect anybody to jump up and shout "We need this NOW", but I don't really get what exactly would be wrong about keeping this task and having someone (that may be me when I finally have time in a few days) work on it if they like.

The only thing I've heard so far that sounds like a real reason to me why it would be especially bad if we'd implement this is

As such, I'm not inclined to add even more complexity to the logic.

I'm not sure how are you supposed to add new features without adding some logic. This seems a weak argument to me.

If there is anything more that would be especially bad in doing this, please share.

In T161595#3136823, @EddieGP wrote:

As far as I can see, there are no groups on the WMF cluster with such permissions, and I see this as a purely hypothetical situation.

This may be true or not, I really don't know. I tend to trust you on this.

You can convince yourself of this by looking through the configuration of $wgAddGroups and $wgRemoveGroups in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php.

As such, I'm not inclined to add even more complexity to the logic.

I'm not sure how are you supposed to add new features without adding some logic. This seems a weak argument to me.

The key word there was "complexity", not "logic".

If there is anything more that would be especially bad in doing this, please share.

If you'd like to implement it I'm not going to stop you, but you'd be well advised to spend your time addressing other tasks first.

@TTO: So what capabilities did you end up implementing for users who have both add and remove rights? Can they shorten the duration of a right, or do they have to remove the right and re-add it with a shorter length?

To clarify this again, once again, currently it is:

So, @kaldari, the answer to your question is: Users who can both add and remove rights can do whatever they want with user groups and group expiry. They may add or remove user rights, extend or shorten group expiry in any way for each and every user right they are able to both add and remove. Just as one would expect for somebody who is allowed to both add and remove some right.

I'm going to change the task title now. I chose it because I hate task titles that are far too long, but this one seems just to confuse people.

Considering the lack of an actual use case (rather than a hypothetical use case), I'm inclined to agree with TTO and support declining the task. To quote The 12 Principles of Agile Software: "Simplicity—the art of maximizing the amount of work not done—is essential." Although EddieGP's request makes sense from a logical perspective, we should never add complexity for hypothetical use cases. At least that's my opinion :)

Touché!

> Anyway, anyone with a real use case is very much invited to re-open this task and explain their case.

On zhwiki, patrollers, rollbackers and users with the IPBE right are able to remove those rights from their own account while cannot add them. Take IPBE as an instance: If an editor in US plans to stay in China during the next three months, a sysop from zhwiki may grant him the IPBE right with the expiry of three months, in order to help him bypass the firewall. However, if his plan changes, and he no longer needs this right for such a long time, he cannot shorten the expiry by himself. This doesn't seem reasonable.

In T161595#4072883, @Antigng wrote:

However, if his plan changes, and he no longer needs this right for such a long time, he cannot shorten the expiry by himself. This doesn't seem reasonable.

That doesn't sound right. The intention was that if you can only remove the right and not add it, you should be able to shorten the expiry but not lengthen it. Will have to check this As EddieGP has pointed out, what I wrote was wrong.

Maybe I'm getting it wrong, but your comment sounds to me like you'd expect mw to already work that way. That's confusing me, because as I get it the implementation for this use case (user able to remove but not add right) works exactly like discussed in the comments above (user should not able to change expiry at all, neither shortening or lengthening it). To implement what you described (shorten the expiry but not lengthen it) was the intention of this very task, which we declined. So now that we know the use case isn't purely hypothetical, we might want to consider re-opening it. I'm not sure what doesn't sound right about how it works now or what needs to be checked though. This isn't meant to sound harsh in any way, I'm just honestly confused by your comment.

This is why we declined it:

In T161595#3136635, @MarcoAurelio wrote:

I do not know in which strange scenario a user will be able to remove a
right that cannot add themselves. If there's any, please share. Thank you.

Since there is now a use-case, let's reopen this task.

In T161595#4074329, @EddieGP wrote:

I'm just honestly confused by your comment.

This is what happens when I don't bother to reread the task description...