Page MenuHomePhabricator

Allow users who can remove but not add a right to shorten userrights expiry
Open, LowestPublic

Description

Currently, users who have for example

$wgAddGroups['bureaucrat']['sysop'] = true;
$wgRemoveGroups['bureaucrat']['sysop'] = false; //Just to make a point here.

can extend the expiry of a user right, but can not shorten it's duration. The opposite isn't supported. Users who have e.g.

$wgAddGroups['bureaucrat']['sysop'] = false; //see above
$wgRemoveGroups['bureaucrat']['sysop'] = true;

can't manipulate the user rights expiry in any way, which means they aren't able to shorten a user rights expiry as one would expect.

This is a child of T156784 because that one introduced the feature/security fix that implements a "You can only extend the duration, not shorten it" rule and the change described here was already discussed there.

Event Timeline

EddieGP removed TTO as the assignee of this task.Mar 28 2017, 9:28 AM
EddieGP created this task.

Sorry, I didn't mean to assign this to you, forgot to remove this at child task creation.

EddieGP updated the task description. (Show Details)Mar 28 2017, 9:29 AM
TTO triaged this task as Lowest priority.Mar 28 2017, 9:37 AM

This was on purpose, articulated in T159416:

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

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. As such, I'm not inclined to add even more complexity to the logic.

I'm very tempted to decline this.

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.

EddieGP added a comment.EditedMar 28 2017, 10:05 AM

@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.

TTO added a comment.Mar 28 2017, 11:05 PM

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?

EddieGP added a comment.EditedApr 7 2017, 12:44 AM

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

User can add rightUser can remove rightOutcome
nonoCan't change user rights or expiry at all
yesnoCan add user groups and prolong group expiry time. Cannot remove groups or shorten user group rights
noyesCan remove user groups. Cannot change group expiry in any way. User is even unable to shorten group expiry<---- THIS is what this tasks aims to change, making those users able to shorten expiry
yesyesCan add and remove user groups and change group expiry in any way they like

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.

EddieGP renamed this task from Allow to shorten userrights expiry to Allow users who can remove but not add a right to shorten userrights expiry.Apr 7 2017, 12:44 AM

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 :)

EddieGP closed this task as Declined.Apr 7 2017, 1:19 AM

Although EddieGP's request makes sense from a logical perspective, we should never add complexity for hypothetical use cases.

Although I mostly agree on this, I don't think it is good to have non-logical software either. But that doesn't mean this is priority.

To quote The 12 Principles of Agile Software: "Simplicity—the art of maximizing the amount of work not done—is essential."

Though I'm really uncomfortable with that, I agree that there is a reason these rules exist and that it's very likely a good idea to follow them. To cover up another:

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

> 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.

TTO added a comment.EditedMar 22 2018, 9:03 PM

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.

TTO added a comment.Mar 22 2018, 11:07 PM

This is why we declined it:

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.

I'm just honestly confused by your comment.

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

TTO reopened this task as Open.Mar 22 2018, 11:07 PM
Jony added a subscriber: Jony.Thu, Jan 23, 5:59 AM