In T376315#10591254, @gerritbot wrote:

Change #1103442 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Update automatic global group membership on global group change

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

Seems to have caused T387523: TypeError: MediaWiki\Permissions\UltimateAuthority::__construct(): Argument #1 ($actor) must be of type MediaWiki\User\UserIdentity, bool given

In T376315#10593688, @Reedy wrote:

In T376315#10591254, @gerritbot wrote:

Change #1103442 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Update automatic global group membership on global group change

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

Seems to have caused T387523: TypeError: MediaWiki\Permissions\UltimateAuthority::__construct(): Argument #1 ($actor) must be of type MediaWiki\User\UserIdentity, bool given

Won't have been that change, given that it was only merged a day ago.

A previous patch for this task did cause it. Not sure how this wasn't seen sooner, but won't be able to deploy a fix for this until Monday given no deployments on the weekend.

The fix will likely involve making a MediaWiki system user do the global groups change if there is no associated performer.

Change #1124066 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CentralAuth@master] Prevent automatic groups causing updates to other automatic groups

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

Change #1124067 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CentralAuth@master] Document that automatic global groups don't work with autopromote

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

Thanks @Reedy and @Dreamy_Jazz for finding and fixing the problem!

I think we are OK to explicitly not support updating automatic global groups in response to autopromotion:

• We do not need it for our use of the feature, which involves groups that confer sensitive rights.
• We don't currently update automatic global groups in response to autopromotion (normal, as opposed to autopromoteonce) - we'd need to handle onGetAutoPromoteGroups. We'd also need to make decisions about whether to allow taking the automatically-added groups away somehow, or implement implicit automatic global groups that are calculated on the fly, similar to autopromotion.
• It would also be difficult to support automatic global groups causing other automatic global groups to update, since this would need to be checked repeatedly as more global groups are updated.

The new commits formalize not supporting autopromotion.

Change #1124066 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Prevent automatic groups causing updates to other automatic groups

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

Change #1124067 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Document that automatic global groups don't work with autopromote

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

• The maintenance script createAndPromote.php also ensures these groups stay in sync

I had a look into this - here's a summary.

createAndPromote basics

• This is a maintenance script that allows users to be promoted into one of the following groups: 'sysop', 'bureaucrat', 'interface-admin', 'bot'.
• If $wgCentralAuthAutomaticGlobalGroups was configured with one of these groups, the groups would not be updated accordingly, as it stands.

Why are the groups not updated?

• createAndPromote calls UserGroupManager::addUserToMultipleGroups, which eventually runs the hook UserAddGroup.
• It never runs the hook that we currently listen to for local changes, UserGroupsChanged.

What could we do to ensure the groups are updated?

• We could handle UserAddGroup from CentralAuth, and update the global groups. But the hook is run before the change is made, so the change might not go through, and the groups would be out of sync.
• We could run UserGroupsChanged from createAndPromote (or anywhere else in the pathway called from it), but this would have a lot of side effects because there are many handlers.
• We could run a new hook from createAndPromote just for this.
• We could document in createAndPromote documentation that automatic global groups will not be updated, so must be updated manually.

Reccommendation
I'd recommend updating the createAndPromote documentation, because the allowed groups are not relevant to our use-case in this task, and it's not clear that there will be any more use-cases. (I'm already a little concerned that we've over-engineered a solution to the specific problem of keeping the IP reveal global group in sync.)

Change #1127960 had a related patch set uploaded (by Tchanders; author: Tchanders):

[operations/mediawiki-config@master] Set $wgCentralAuthAutomaticGlobalGroups for global IP reveal group

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

Change #1128355 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/core@master] createAndPromote: Add documentation about automatic global groups

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

Change #1128355 merged by jenkins-bot:

[mediawiki/core@master] createAndPromote: Add documentation about automatic global groups

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

Moving this task to QA for testing before we deploy. Where the acceptance criteria say "WMF wiki", it should work on the local wiki.

Testing steps
These steps include how to set up the local environment to use the same-named groups as WMF production, for simplicity.

Setup:

• Ensure that CheckUser and CentralAuth are loaded. In LocalSettings.php:

wfLoadExtension('CheckUser');
wfLoadExtension('CentralAuth');

• Log in as a user with userrrights, globalgrouppermissions and globalgroupmembership. By default, bureaucrat has userrights. Assign the other permissions using:

$wgGroupPermissions['bureaucrat']['globalgrouppermissions'] = true;
$wgGroupPermissions['bureaucrat']['globalgroupmembership'] = true;

• Create the global groups global-sysop and global-temporary-account-viewer using Special:GlobalGroupPermissions. (It doesn't matter which permissions are assigned to the groups.) Ensure no local groups have the same names as these global groups.
• Set the $wgCentralAuthAutomaticGlobalGroups config similarly to https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1127960/3/wmf-config/CommonSettings.php

Testing:

• At Special:UserRights, enter a user who has no rights. Assign checkuser or suppress. At Special:GlobalUserRights for the same user, temporary account IP viewer should now be checked. Test that adding various combinations of these local groups checks or unchecks temporary account IP viewer according to the acceptance criteria.
• Test the same thing at Special:GlobalUserRights, adding and removing the global groups as well.
• Repeat the test at Special:UserRights with a user who does not have the globalgroupmembership right. The global groups should still be updated correctly.
• Check that all the activity was logged appropriately at Special:Log?type=gblrights
• Assign some of these groups with different expiries. Ensure that the temporary account IP viewer is assigned with the latest of these expiries.

The patch to configure the wikis currently won't work because abusefilter-helper is also a local group on enwiki (thanks @Dreamy_Jazz for pointing this out). The config as it stands would cause everyone in this local group to be added to the global-temporary-account-viewer group: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1127960/1/wmf-config/CommonSettings.php#4123

Could we change the name of the global AbuseFilter groups to add a global- prefix, so global-abusefilter-maintainer and global-abusefilter-helper? I understand this would take some work, to add the groups, move the users and delete the old groups, but it would be nice to clarify that these groups are global (especially since the naming convention is used for many of the other global groups).

Would someone be happy to do this?

There are some more tricky cases to check:
(1) In some wikis CheckUser is a termed role, i.e. user may get temporary CheckUser for one year. When their access expired, what will happen?

• Their checkuser-temporary-account-viewer group is kept as-is (bad)
• Their checkuser-temporary-account-viewer group is only removed when rows in user_groups are purged. (Probably OK, but needs agreement)
• They are only assigned temporary checkuser-temporary-account-viewer access as long as they are not in other groups granting checkuser-temporary-account-viewer access (and if the expiry of CheckUser access is modified, the expiry should also be modified too)

(2) The most often use case of temporary CheckUser access is by stewards, who do not have global CheckUser access by itself but can assign local CheckUser access, and already has access to IP reveal globally. They should be excluded from $wgCentralAuthAutomaticGlobalGroups

• i.e. A user who become a steward will lose checkuser-temporary-account-viewer group, but a user with local CU/OS losing steward will gain checkuser-temporary-account-viewer group.
• Otherwise, if a steward (without local CU/OS) does not have checkuser-temporary-account-viewer group, they will receive/revoke checkuser-temporary-account-viewer group each time they assign local CU/OS, which just causes noise.
  • Note the above point does not happen currently, since all stewards has CheckUser in loginwiki, but this will change once T299869: Per-permission wiki set restrictions is resolved.

(3) After this change, if steward assigns checkuser-temporary-account-viewer group to an otherwise ineligible user for whatever reason, this will causes issue (such group will be automatically revoked on unrelated user right change). This is currently OK since the policy does not allow otherwise ineligible user to request such group explicitly, but once we decided to allow this, a different user group must be created.

In T376315#10651801, @Tchanders wrote:

Could we change the name of the global AbuseFilter groups to add a global- prefix, so global-abusefilter-maintainer and global-abusefilter-helper? I understand this would take some work, to add the groups, move the users and delete the old groups, but it would be nice to clarify that these groups are global (especially since the naming convention is used for many of the other global groups).

Would someone be happy to do this?

Before the stewards can do the rename, we need to create the associated i18n messages in WikimediaMessages for the global group. @Tchanders could you work on this? It would be a patch similar to https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaMessages/+/c5e907d4e72fa2881fb52c94fbc0d8ce01fb24cc

Change #1139064 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/WikimediaMessages@master] Add messages for global abusefilter groups

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

Change #1139064 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Add messages for global abusefilter groups

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

@KColeman-WMF Here is how Special:GlobalUserRights would look currently. The checkbox for checkuser-temporary-account-viewer is misleading, because it will be automatically assigned depending on the other groups.

Thanks @Tchanders. Here are my suggestions for making the UI clearer:

Scenario	Mockup
User has not been automatically assigned checkuser-temporary-account viewer
User has been automatically assigned checkuser-temporary-account viewer

Change #1146572 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CentralAuth@master] WIP Handle expiries in automatic global groups

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

@Bugreporter Thanks for raising these points.

In T376315#10655196, @Bugreporter wrote:

There are some more tricky cases to check:
(1) In some wikis CheckUser is a termed role, i.e. user may get temporary CheckUser for one year. When their access expired, what will happen?

• Their checkuser-temporary-account-viewer group is kept as-is (bad)
• Their checkuser-temporary-account-viewer group is only removed when rows in user_groups are purged. (Probably OK, but needs agreement)
• They are only assigned temporary checkuser-temporary-account-viewer access as long as they are not in other groups granting checkuser-temporary-account-viewer access (and if the expiry of CheckUser access is modified, the expiry should also be modified too)

The latest patch should fix this: https://gerrit.wikimedia.org/r/1146572 - it adds an expiry to the automatic global group, which gets adjusted whenever other group expiries are adjusted, as suggested in the third option.

(2) The most often use case of temporary CheckUser access is by stewards, who do not have global CheckUser access by itself but can assign local CheckUser access, and already has access to IP reveal globally. They should be excluded from $wgCentralAuthAutomaticGlobalGroups

• i.e. A user who become a steward will lose checkuser-temporary-account-viewer group, but a user with local CU/OS losing steward will gain checkuser-temporary-account-viewer group.
• Otherwise, if a steward (without local CU/OS) does not have checkuser-temporary-account-viewer group, they will receive/revoke checkuser-temporary-account-viewer group each time they assign local CU/OS, which just causes noise.
  • Note the above point does not happen currently, since all stewards has CheckUser in loginwiki, but this will change once T299869: Per-permission wiki set restrictions is resolved.

I'd suggest fixing this in a follow-up task, partly to contain the scope of this task. It could be done after T299869, or log noise could be reduced by just adding global-temporary-account-viewer if a user has steward (thanks @Dreamy_Jazz for that suggestion).

(3) After this change, if steward assigns checkuser-temporary-account-viewer group to an otherwise ineligible user for whatever reason, this will causes issue (such group will be automatically revoked on unrelated user right change). This is currently OK since the policy does not allow otherwise ineligible user to request such group explicitly, but once we decided to allow this, a different user group must be created.

We've discussed this a bit and I think we're not 100% decided whether stewards should be allowed to override the global group being added automatically. For now, we've decided to go ahead with implementing this feature, and we can configure it "on" if we don't think the stewards will need to override it, and configure it "off" if it turns out they do need to override it. If we find ourselves in this position, we can reconsider what we want to do here.

(In general I feel a bit wary of having the software become too complicated, adding the group automatically in some cases, but having various exceptions - it might become too complicated a user experience.)

Change #1146572 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Handle expiries in automatic global groups

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

Moving this to QA. Testing steps are in an earlier comment: T376315#10651771.

Implementing the UI from T376315#10801972 is filed as a separate task: T394933: Automatic global groups: Update UI to indicate when group is assigned automatically

QA is completed, I have verified the new code changes have been implemented and is functioning as expected (per the Acceptance Criteria).

In T376315#10867446, @Tchanders wrote:

Reopening this, since the task description includes the functionality in production.

Once the config patch is deployed (https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1127960) we can close it again. Moving back to the review column.

This has been reviewed and is awaiting the subtask: T394933: Automatic global groups: Update UI to indicate when group is assigned automatically.

Change #1127960 merged by jenkins-bot:

[operations/mediawiki-config@master] Set $wgCentralAuthAutomaticGlobalGroups for global IP reveal group

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

Mentioned in SAL (#wikimedia-operations) [2025-06-16T13:08:46Z] <phuedx@deploy1003> Started scap sync-world: Backport for [[gerrit:1156872|ext-EventStreamConfig: Update product_metrics.web_base stream (T395692)]], [[gerrit:1127960|Set $wgCentralAuthAutomaticGlobalGroups for global IP reveal group (T376315)]], [[gerrit:1153307|Enable temporary accounts onboarding dialog on WMF wikis (T395933)]], [[gerrit:1139808|Change citoid config for test wiki (T361576)]]

Mentioned in SAL (#wikimedia-operations) [2025-06-16T13:10:40Z] <phuedx@deploy1003> phuedx, mvolz, dreamyjazz, tchanders: Backport for [[gerrit:1156872|ext-EventStreamConfig: Update product_metrics.web_base stream (T395692)]], [[gerrit:1127960|Set $wgCentralAuthAutomaticGlobalGroups for global IP reveal group (T376315)]], [[gerrit:1153307|Enable temporary accounts onboarding dialog on WMF wikis (T395933)]], [[gerrit:1139808|Change citoid config for test wiki (T361576)]] synced to t

@Tchanders I just noticed https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60233439 and https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60233524 which surprised me because both users are stewards.

Once stewards assign CU or OS permissions to their accounts on some local wiki, they automatically get global-temporary-account-viewer permissions even though they already have global access. I tested this to confirm: https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60235684 -> https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60235683

Please make an exemption so that automatic assignment doesn't happen to stewards. And while we are at it: Please make the same exemption for ombuds, multiple members in https://meta.wikimedia.org/wiki/Special:GlobalUsers/ombuds have global-temporary-account-viewer (e.g. because they are global sysops) even though the group is redundant to their ombuds permissions.

Potential problem: What happens, if a steward / ombuds member resigns but keeps their existing CU/OS permissions on some local project – as far as I understand the automatic assignment only works when CU/OS are added? How will they get global-temporary-account-viewer?

Unfortunately we cannot manually remove the global group, please un-assign global-temporary-account-viewer from the following stewards: EPIC, Xaosflux, Johannnes89 and the following ombuds: Ameisenigel, Faendalimas, Renvoy, Revi C., RoySmith, Teles

In T376315#10920524, @Johannnes89 wrote:

@Tchanders I just noticed https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60233439 and https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60233524 which surprised me because both users are stewards.

Once stewards assign CU or OS permissions to their accounts on some local wiki, they automatically get global-temporary-account-viewer permissions even though they already have global access. I tested this to confirm: https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60235684 -> https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60235683

Please make an exemption so that automatic assignment doesn't happen to stewards. And while we are at it: Please make the same exemption for ombuds, multiple members in https://meta.wikimedia.org/wiki/Special:GlobalUsers/ombuds have global-temporary-account-viewer (e.g. because they are global sysops) even though the group is redundant to their ombuds permissions.

Thanks for pointing this out - exemptions weren't in the original feature spec, so we'd have to add this functionality in.

Potential problem: What happens, if a steward / ombuds member resigns but keeps their existing CU/OS permissions on some local project – as far as I understand the automatic assignment only works when CU/OS are added? How will they get global-temporary-account-viewer?

Automatic assignment is updated when groups change, so the global IP reveal group will be added or removed, or the expiry updated, accordingly. (This was raised in T376315#10655196 too.)

Unfortunately we cannot manually remove the global group, please un-assign global-temporary-account-viewer from the following stewards: EPIC, Xaosflux, Johannnes89 and the following ombuds: Ameisenigel, Faendalimas, Renvoy, Revi C., RoySmith, Teles

Overrides aren't currently possible, when the feature is enabled. I mentioned at the end of T376315#10827629 that overrides might be needed, but we had consensus to go ahead without overrides, and switch it off again if there were problems raised.

All in all, it sounds as though the best way forward would be to disable the feature again, and have another round of specification, so we know exactly what we need. cc @Niharika

In T376315#10920602, @Tchanders wrote:

In T376315#10920524, @Johannnes89 wrote:

@Tchanders I just noticed https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60233439 and https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60233524 which surprised me because both users are stewards.

Once stewards assign CU or OS permissions to their accounts on some local wiki, they automatically get global-temporary-account-viewer permissions even though they already have global access. I tested this to confirm: https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60235684 -> https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=60235683

Please make an exemption so that automatic assignment doesn't happen to stewards. And while we are at it: Please make the same exemption for ombuds, multiple members in https://meta.wikimedia.org/wiki/Special:GlobalUsers/ombuds have global-temporary-account-viewer (e.g. because they are global sysops) even though the group is redundant to their ombuds permissions.

Thanks for pointing this out - exemptions weren't in the original feature spec, so we'd have to add this functionality in.

Did we discuss automatically giving the global group to stewards and ombuds to solve this? However, that might not be ideal if we want to avoid having stewards be given another global group.

Change #1159580 had a related patch set uploaded (by Tchanders; author: Tchanders):

[operations/mediawiki-config@master] Revert "Set $wgCentralAuthAutomaticGlobalGroups for global IP reveal group"

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

Overrides aren't currently possible, when the feature is enabled. I mentioned at the end of T376315#10827629 that overrides might be needed, but we had consensus to go ahead without overrides, and switch it off again if there were problems raised.

See: T389808#10806527

In T376315#10921004, @Bugreporter wrote:

Overrides aren't currently possible, when the feature is enabled. I mentioned at the end of T376315#10827629 that overrides might be needed, but we had consensus to go ahead without overrides, and switch it off again if there were problems raised.

See: T389808#10806527

Ah thanks, I was looking for that conversation earlier but didn't manage to find it. I made some suggestions in the following comments why global automatic groups might not work too well as a feature, depending on how much flexibility is needed.

In T376315#10920607, @Dreamy_Jazz wrote:

Did we discuss automatically giving the global group to stewards and ombuds to solve this? However, that might not be ideal if we want to avoid having stewards be given another global group.

True, we did discuss that doing this would solve the logs but add a redundant group to more users. I took from @Johannnes89's comment redundant groups would also a problem...

Change #1159987 had a related patch set uploaded (by Tchanders; author: Tchanders):

[operations/mediawiki-config@master] Assign global IP viewer to stewards, to avoid log spam

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

There are a few things we could do to follow up here:

• Remove the config changes, so groups are no longer added automatically: https://gerrit.wikimedia.org/r/1159580
• Update the config to assign global IP reveal to stewards, to avoid the extra log noise when they are added to local groups: https://gerrit.wikimedia.org/r/1159987
• Leave as-is.

We'll await feedback before changing or removing the config.

We can also look into doing some more work on this feature, perhaps so it could work a bit more like local auto-promote, including the ability to add conditions under which the user should not be autopromoted.