Allow admins adding confirmed user group on all WMF wikis
Open, LowestPublic

Description

In T101981: Admin could not set "confirmed users" it's reported that admins can not set "confirmed users" flags. Confirmed users only have few extra rights and enabling this doesn't harm anything. So probably we can allow admins adding confirmed user group on all WMF wikis.

Bugreporter updated the task description. (Show Details)
Bugreporter raised the priority of this task from to Needs Triage.
Bugreporter added a subscriber: Bugreporter.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 10 2015, 2:06 PM

Does code to support this already exist in MediaWiki and is this only about enabling executing that code (hence a setting on Wikimedia servers)? Or does code not exist to support this (hence a request to write some code in MediaWiki?)

Bugreporter added a comment.EditedJun 10 2015, 2:39 PM

There're two possible solution:

  • Modify "wgAddGroups" variable. of InitialiseSettings.php (simple but only work in WMF)
  • Create a "confirmed" group at MediaWiki software which is equal to autoconfirmed but can be granted by sysops. (complicated, not recommended)

Note every WMF wikis have a confirmed user group but no one but stewards and sysadmins can add it currently.

  • Modify "wgAddGroups" variable. of InitialiseSettings.php (simple but only work in WMF)

    Note every WMF wikis have a confirmed user group but no one but stewards and sysadmins can add it currently.

That's not true, administrators of some WMF wikis can do it as well. Please actually read the config before making such statements.

  • Create a "confirmed" group at MediaWiki software which is equal to autoconfirmed but can be granted by sysops. (complicated, not recommended)

Adding a 'confirmed' group to the default MediaWiki core groups is a separate subject for another task. This won't affect WMF wikis anyway, which seems to be what you want.

Krenair set Security to None.

Yes administrators of some WMF wikis can do it as well, but every wiki community must open a new task before start using the group.

I'm going to limit this task to WMF wikis.

Bugreporter renamed this task from Allow admins adding confirmed user group on all wikis to Allow admins adding confirmed user group on all WMF wikis.Jun 10 2015, 3:33 PM
Bugreporter updated the task description. (Show Details)

Yes... I do wonder whether you should have a conversation on meta before simply opening up an admin-controlled group on all wikis though. @MarcoAurelio, would you mind commenting here? Thanks.

Hi. If I remember rightly, now the "confirmed" flag exist on all wikis (checked some random wikis and found it at special:listgrouprights on all of them), but can only be added by stewards (or other users with the 'userrights'/'userrights-interwiki' permissions) by default (please correct me if I am wrong).

We have received some requests in the past at SRP to assign this permission. I personally think that it is not a dangerous right, but I'd probably ask at [[m:Wikimedia Forum]] whether people wants to change the current status quo, as the right currently holds more than the 'confirmed' permission.

The autoconfirm limits were stablished to primary avoid spam and page move vandalism. There should be a reason to override the system IMHO.

the "confirmed" flag exist on all wikis

Yep.

can only be added by stewards (or other users with the 'userrights'/'userrights-interwiki' permissions) by default (please correct me if I am wrong).

By default, yep. Some wikis allow their admins (or in the case of eswiki, eswikivoyage, frwiktionary and eswikibooks: bureaucrats) to do it - ctrl+f "'confirmed'" at https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L8318

I'd probably ask at [[m:Wikimedia Forum]] whether people wants to change the current status quo, as the right currently holds more than the 'confirmed' permission.

Want to do that, @Bugreporter? I think it only additionally grants skipcaptcha, but otherwise matches autoconfirmed?

btw, imo admin and editor user groups should inherit autoconfirmed too. some of the users with editor status who lost their autoconfirmed lamented that they couldn't move, upload, and have to fill captcha. Or is that for another task?

btw, imo admin and editor user groups should inherit autoconfirmed too. some of the users with editor status who lost their autoconfirmed lamented that they couldn't move, upload, and have to fill captcha. Or is that for another task?

Editor group? Wasn't that something for FlaggedRevs?
Groups can't inherit rights from other groups, you'd have to manually set it up to grant all the additional rights. This would be a separate task.

btw, imo admin and editor user groups should inherit autoconfirmed too. some of the users with editor status who lost their autoconfirmed lamented that they couldn't move, upload, and have to fill captcha. Or is that for another task?

Editor group? Wasn't that something for FlaggedRevs?
Groups can't inherit rights from other groups, you'd have to manually set it up to grant all the additional rights. This would be a separate task.

Yes editor is a default usergroup in FlaggedRevs. However, it was also used on other projects that I didn't think had FlaggedRevs enabled (e.g., it was available on MediaWiki Wiki).

it was also used on other projects that I didn't think had FlaggedRevs enabled (e.g., it was available on MediaWiki Wiki).

MediaWiki.org used FlaggedRevs until relatively recently, the editor group went away when that was disabled.

Hydriz added a subscriber: Hydriz.Jun 15 2015, 9:02 AM
Meno25 added a subscriber: Meno25.Jul 13 2015, 1:24 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 13 2015, 1:24 PM

@MarcoAurelio: What do you think of the result of that discussion? It seems like we should we just do this?

@MarcoAurelio: What do you think of the result of that discussion? It seems like we should we just do this?

Given that I participated in the discussion (archived here now) I'd prefer others to assess the result. However I'm taking the liberty to make a personal summary:

Reading the discussion I see that most commenting there are in favor (sysops are trusted and this right is not very dangerous) but there are also some concerns such as if this may be really useful. See @Vogone's points for this. It is also important to state that what he says is true: if small wiki admins can do it, stewards will in principle abstain from doing this, so the whole point of granting the confirmed flag may become void if the user has to wait for small wiki sysops to reply, then asking stewards. In most cases the user will become autoconfirmed themself.

There's also an interesting point in that wikis that really need to grant this in a regular basis already have this configured. The right does not seem to be very used though.

Another concern is maybe the low participation in the discussion. While not a super breaking change, maybe I'd have expected more participation.

As I've said, I'll let others to decide on this. Thanks.

Luke081515 triaged this task as Normal priority.Dec 9 2015, 8:44 AM

On the other hand we can go ahead with a more conservative approach. Let bureaucrats on WMF wikis do this. That'll aleviate the concerns of small wikis and maybe overuse. If a wiki has bureaucrats is probably big enough to deal with this and now being able to grant userrights temporary, this could be useful.

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptJul 31 2017, 9:23 PM

Change 368939 had a related patch set uploaded (by MarcoAurelio; owner: MarcoAurelio):
[operations/mediawiki-config@master] Allow bureaucrats on WMF wikis to grant and remove 'confirmed'

https://gerrit.wikimedia.org/r/368939

Shouldn't the confirmed right also be removed from the wiki overrides since it would be default?

If the patch is approved we can later see how many wikis do grant this to bureaucrats and remove them as it'll duplicate the default settings. If there are wikis that have decided to give this to other groups they should be left.

@Dereckson Can you raise this to ops@lists and see if there are any qualms or objections?

Thanks.

MarcoAurelio lowered the priority of this task from Normal to Low.Aug 7 2017, 6:21 PM

To reflect the current task status. It is not urgent but as I'm somewhat working on this one it's not lowest; although it may require some more consideration I've already uploaded a patch for this and pinged some people for their opinion on this. A discussion between us is happening at Conpherence and I do not discard re-asking on Meta if really needed.

From an ops point of view, this change doesn't create any change on the servers infrastructure.

So it's more a social question, about the users' rights power balance.

The previous discussions both here and on meta shows support for the change.

In a nutshell, the change offers a comfortable way to deal with a little scope issue "accounts < 4 days we want to trust now to rename pages or upload files".
And we offer this tiny possibility to trusted people to deal with access.

As such, we can process this without further re-asking.

Change 368939 merged by jenkins-bot:
[operations/mediawiki-config@master] Allow bureaucrats on WMF wikis to grant and remove 'confirmed'

https://gerrit.wikimedia.org/r/368939

Mentioned in SAL (#wikimedia-operations) [2017-08-08T23:23:16Z] <dereckson@tin> Synchronized wmf-config/InitialiseSettings.php: Allow bureaucrats on WMF wikis to grant and remove 'confirmed' (T101983) (duration: 00m 51s)

So for bureaucrats, it's done.

Next step is to discuss the sysop part.

Change 370787 had a related patch set (by MarcoAurelio) published:
[operations/mediawiki-config@master] Follow-up Ia62ad0f4

https://gerrit.wikimedia.org/r/370787

User-notice: Bureaucrats on Wikimedia wikis can now add and remove the 'confirmed' user group. Previously only stewards could do that, or wikis had to request a configuration change to allow this permission to be managed locally. Wikis that decided in the past to have this permission be manageable by other groups such as "administrators" are not affected and their administrators will not loose the ability to continue managing this permission

My English sucks so I'd appreciate rewording/copyedit/etc. Please note that we should have https://gerrit.wikimedia.org/r/370787 merged first so they're also able to remove the permission (an oversight I had in the first patch).

@Dereckson Once the follow-up patch is merged I'd call this resolved. Wikis do not loose the ability to decide that sysops should be able to grant/remove this permission as well. I'm not sure if we'll receive more requests for SITECONFIG changes with regards to this. Big wikis where this was often needed have had their configuration changed already, for others we've just empowered their bureaucrats to do so. In case the wiki does not have local bureaucrats, they can still ask us (stewards). And since now assigning a permission can be done temporarily as well, it is very unlikely that it doubles our work as the permission will automatically expire and users won't need to come back and request its deflag.

If we think however that it is best that sysops do this everywhere, let's hold a RfC here at Phabricator and see their pro/cons. I'm however happy with this current solution and I think we should allow some time to see if it works fine.

Regards.

Change 370791 had a related patch set uploaded (by TerraCodes; owner: TerraCodes):
[operations/mediawiki-config@master] Update InitialiseSettings.php

https://gerrit.wikimedia.org/r/370791

Change 370787 merged by jenkins-bot:
[operations/mediawiki-config@master] Follow-up Ia62ad0f4

https://gerrit.wikimedia.org/r/370787

Mentioned in SAL (#wikimedia-operations) [2017-08-09T13:18:58Z] <ladsgroup@tin> Synchronized wmf-config/InitialiseSettings.php: Allow bureaucrats remove confirmed user group (T101983) (duration: 00m 51s)

User-notice: Bureaucrats on Wikimedia wikis can now add and remove the 'confirmed' user group. Previously only stewards could do that, or wikis had to request a configuration change to allow this permission to be managed locally. Wikis that decided in the past to have this permission be manageable by other groups such as "administrators" are not affected and their administrators will not loose the ability to continue managing this permission

My English sucks so I'd appreciate rewording/copyedit/etc. Please note that we should have https://gerrit.wikimedia.org/r/370787 merged first so they're also able to remove the permission (an oversight I had in the first patch).

The follow-up patch is now merged. I think I'm not closing this task yet until the User-notice team picks this for the next issue. Suggests on new wording for the announcement are welcome :)

Johan added a subscriber: Johan.Aug 9 2017, 3:55 PM

Added to the current draft after some simplification:
https://meta.wikimedia.org/wiki/Tech/News/2017/33

Hi @Johan. Thanks for that. Could it be modified to "Bureaucrats can now add and remove the confirmed user group on Wikimedia wikis..." instead? Thanks.

Johan added a comment.Aug 9 2017, 6:49 PM

@MarcoAurelio The reason I tried to rephrase it (and I'm not saying my solution is perfect) is that in my experience, if we write something about "adding a user group", a lot of non-technical users won't understand that this means changing the user rights of individual editors. To them, "adding a user group" sounds like adding a user group that previously didn't exist at the wiki.

@Johan Fair enough. Can I close this task or want to keep it open until the Tech news issue is delivered? Regards.

Johan added a comment.Aug 9 2017, 9:15 PM

With that said, if you have a better way of phrasing it, please just go ahead and edit (within the next 24 hours or so). (:

I'd say you can close it.

MarcoAurelio closed this task as Resolved.Aug 10 2017, 6:51 AM
MarcoAurelio removed a project: Patch-For-Review.
MarcoAurelio claimed this task.
MarcoAurelio moved this task from ready to archive on the User-MarcoAurelio board.
TerraCodes reopened this task as Open.Aug 10 2017, 7:16 AM
TerraCodes added a project: Patch-For-Review.

All patches have not been merged/abandoned.

This task is resolved IMHO. The other patch is related to a cleanup that was not discussed nor approved. I suggest that we raise that in other task, although it'd be premature without giving time to time and check how the solution we've implemented works. I'm not going to war with the statuses though.

The other patch is related to a cleanup that was not discussed nor approved.

Approved?

+2, merged, etc.

MarcoAurelio lowered the priority of this task from Low to Lowest.Sun, Sep 3, 10:17 AM