Page MenuHomePhabricator

add wmf-supportsafety user group on meta
Closed, ResolvedPublic

Description

In prep for changes to staff rights (and to allow for better logging/transparency) we want to create wmf-supportsafety with the following user rights:

  • userrights-interwiki
  • centralauth-lock
  • globalblock
  • centralauth-rename
  • userrights

Event Timeline

Which groups local, which global? I can create a patch for the local ones. (globalgroupmembership works not as local group)

Which groups local, which global? I can create a patch for the local ones. (globalgroupmembership works not as local group)

I'm actually having Joe do it as part of training. Thanks though!

Preferably all of these should local. I 'think' globalgroupmembership should work globally but if not we'll remove it.

Change 290366 had a related patch set uploaded (by Foks):
Adding Support and Safety global user groups

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

Danny_B renamed this task from Update wmf-officeit user group on meta + and wmf-supportsafety to Update wmf-officeit user group on meta + add wmf-supportsafety.May 24 2016, 12:53 AM
Danny_B removed a subscriber: Wikimedia-Site-requests.

The groups lack a description https://meta.wikimedia.org/wiki/Special_global_permissions . It should be transparent what they are, how people are added/removed, why they have the rights they have and under what policies they use those rights.

In prep for changes to staff rights

Do you mean you will remove such rights from the staff group so that less people will end up having them? Such a multiplication of groups is only acceptable if it reduces attack surface, not if it increases it.

Please don't forget to add the MediaWiki description messages to these
groups on the Wikimedia-Messages extension.

Jalexander renamed this task from Update wmf-officeit user group on meta + add wmf-supportsafety to add wmf-supportsafety user group on meta.May 24 2016, 6:28 AM
Jalexander updated the task description. (Show Details)

(...) Preferably all of these should local. I 'think' globalgroupmembership should work globally but if not we'll remove it.

Tested at some testwikis, it works not. IIRC, there was a bug for it. At the moment it is hardcoded, that these borh rights (globalgroupmembership, globalgrouppermissions) aer working only local. IIRC, @Krenair knows the relevant line, I don't know it anymore :-/.

The groups lack a description https://meta.wikimedia.org/wiki/Special_global_permissions . It should be transparent what they are, how people are added/removed, why they have the rights they have and under what policies they use those rights.

It's a local not a global group but, aye, we'll have a page up similal to https://meta.wikimedia.org/wiki/Meta:WMF_Office_IT before the expected deploy window tomorrow.

In prep for changes to staff rights

Do you mean you will remove such rights from the staff group so that less people will end up having them? Such a multiplication of groups is only acceptable if it reduces attack surface, not if it increases it.

Aye, they will be removed from staff rights immediately after deployment (and giving the local flag to the Support & Safety team specifically). This is modeled after the local steward flag after discussion with them earlier this year and their desire to keep actions such as global locks only on meta (and their recommendation to force that via a local group to avoid accidents).

Over the next couple weeks we will also be migrating people who need the more full "Staff" global rights (mostly Support & Safety staff and others who help with emergency@ on occasion such as certain legal staff) to a new group with signficantly less members. The current Staff right will be retired (with some of those still on it otherwise getting lesser rights to fit their needs).

(...) Preferably all of these should local. I 'think' globalgroupmembership should work globally but if not we'll remove it.

Tested at some testwikis, it works not. IIRC, there was a bug for it. At the moment it is hardcoded, that these borh rights (globalgroupmembership, globalgrouppermissions) aer working only local. IIRC, @Krenair knows the relevant line, I don't know it anymore :-/.

Aye, thanks, Krenair/Lego explained and found the bug and @jrbs patched it out. Weird catch-22 in my opinion but it is what it is. I'm going to talk to the stewards etc to figure out what would be the best option :).

For example we can create global group, which works only at meta, e.g. create a wikiset which includes only meta. Has the same effect, but works more that a local group ;)

Please don't forget to add the MediaWiki description messages to these
groups on the Wikimedia-Messages extension.

Ahh, true, I initially was only going to add locally on meta but that's a good point. We'll make sure to do that as well.

Change 290581 had a related patch set uploaded (by Foks):
Add i18n messages for new Support and Safety group

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

Change 290366 merged by jenkins-bot:
Adding WMF Support and Safety user groups to meta

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

Mentioned in SAL [2016-05-24T23:07:47Z] <dereckson@tin> Synchronized wmf-config/InitialiseSettings.php: Adding WMF Support and Safety user groups to meta (T136046) (duration: 00m 26s)

Change 290581 merged by jenkins-bot:
Add i18n messages for new Support and Safety group

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

Change 290862 had a related patch set uploaded (by Dereckson):
Add i18n messages for new Support and Safety group

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

Change 290862 merged by jenkins-bot:
Add i18n messages for new Support and Safety group

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