Page MenuHomePhabricator

mw.config 'wgGlobalGroups' should only include groups that are active on the current wiki
Closed, ResolvedPublicFeature

Description

With scripts it is possible to check whether you have sysop rights, for example.

if (mw.config.get('wgUserGroups').includes('global-sysop'))

This also works for global groups.
However, this is not always helpful for global sysops and other non-global global groups, as the wikiset must also be checked.
Example the wgGlobalGroups is always. But global-sysop is only in small wikis active.

wgGlobalGroups":["abusefilter-helper","global-ipblock-exempt","global-rollbacker","global-sysop"]

It would be good if you could add a variable with the name "ActiveGlobalGroups" or "RelevantGlobalGroups".

This would have the advantage of making scripts shorter and simpler, and would also reduce the number of API requests that user scripts make in the background.

Event Timeline

Can you share what script you wanted to use this in? Perhaps we might be able to suggest a different approach.

In general we've been trying to avoid adding things to mw.config. Although your idea would reduce the number of API requests that user scripts make (for the few users who enable them), it would also increase the amount of data we send on every page view for every user. For this reason we've previously rejected similar ideas to add things to mw.config for the convenience of user scripts (see e.g. T233175#5501768).

Also, in most cases (although not all), it would be better to check for user rights rather than user groups – that way, you don't need to worry about whether the action is allowed by a global group or a local group. If this would work for your script, you can use mw.user.getRights (documentation), which will also reduce the number of API requests, as all scripts using it share the same cached API request. For example:

if ( ( await mw.user.getRights() ).includes( 'delete' ) ) {  }

If you really need groups (e.g. your script is adding a completely new action that doesn't fit any of the existing user rights), you can fetch both local and global groups using the API: https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&meta=userinfo|globaluserinfo&uiprop=groups&guiprop=groups which returns something like this:

{
    "batchcomplete": true,
    "query": {
        "userinfo": {
            "id": 6423215,
            "name": "Matma Rex",
            "groups": [
                "extendedconfirmed",
                "*",
                "user",
                "autoconfirmed"
            ]
        },
        "globaluserinfo": {
            "home": "plwiki",
            "id": 2605,
            "registration": "2008-05-27T18:34:05Z",
            "name": "Matma Rex",
            "groups": [
                "global-interface-editor"
            ]
        }
    }
}

@WikiBayer Does that help? :)

@matmarex You are right that you can query the scripts the rights, the problem is that the rights are the same whether you are in a global group or in a local group. If you use the global.js and want to distinguish which user group in the wiki you use, you need the groups.

I think you should completely rethink it. In my opinion it would make sense to change or replace variable "wgGlobalGroups ".
Querying the own global groups with mw.config.get does not make sense in its current form. At least I can't think of a sensible purpose for querying global groups that are inactive.

@matmarex You are right that you can query the scripts the rights, the problem is that the rights are the same whether you are in a global group or in a local group. If you use the global.js and want to distinguish which user group in the wiki you use, you need the groups.

But why is that a problem? It would be easier for me to understand if you could show me the script where you want to use this feature.

I think you should completely rethink it. In my opinion it would make sense to change or replace variable "wgGlobalGroups ".
Querying the own global groups with mw.config.get does not make sense in its current form. At least I can't think of a sensible purpose for querying global groups that are inactive.

Oh, I didn't realize that you're talking about a mw.config variable that already exists. I thought that 'wgGlobalGroups' didn't exist, and that you were suggesting adding it.

(Again – I wouldn't have been so confused if you showed me the script that is already using it. Unless it's a secret, please share it.)

Would it be enough to omit the groups that aren't active on the current wiki when generating 'wgGlobalGroups'?

@WikiBayer Would it work for you if, instead of adding a whole new mw.config option, we would omit the groups that aren't active on the current wiki when generating 'wgGlobalGroups'?

@WikiBayer Would it work for you if, instead of adding a whole new mw.config option, we would omit the groups that aren't active on the current wiki when generating 'wgGlobalGroups'?

Yes

matmarex moved this task from Blocked/waiting to Current Sprint on the MediaWiki-Platform-Team board.
matmarex added a project: User-notice.

Okay, let's do it then.

We should probably review the existing uses of the mw.config option: https://global-search.toolforge.org/?q=wgGlobalGroups&namespaces=2,4,8&title=.*\.js – I suspect that most of them already expected it to only include active groups.

Maybe we should also mention this in Tech News.

matmarex renamed this task from Proposal: mw.config.get add relevant/active GlobalGroups to mw.config 'wgGlobalGroups' should only include groups that are active on the current wiki.Feb 13 2024, 6:31 PM

Change 1003068 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Change 'wgGlobalGroups' to only include active groups

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

Change 1003068 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Change 'wgGlobalGroups' to only include active groups

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

Hello @WikiBayer
For Tech News - What wording would you suggest as the content, and When should it be included? Thanks!

Example: wgGlobalGroups, now only contains groups that are active in the wiki. Scripts no longer have to check whether the group is active on the wiki via an API request.

Maybe a code example

if (/globlgroupname/.test(mw.config.get("wgGlobalGroups")))

Example: wgGlobalGroups, now only contains groups that are active in the wiki. Scripts no longer have to check whether the group is active on the wiki via an API request.

Maybe a code example

if (/globlgroupname/.test(mw.config.get("wgGlobalGroups")))

Thanks @WikiBayer, I have added it to the Tech News draft in the "Recent changes" section. Please, let me know if that is accurate.

Thank you @WikiBayer and @UOzurumba for adding the Tech News entry, I've had a very busy couple of days and I didn't remember to do it. The entry looks good to me.

We should probably review the existing uses of the mw.config option: https://global-search.toolforge.org/?q=wgGlobalGroups&namespaces=2,4,8&title=.*\.js – I suspect that most of them already expected it to only include active groups.

Notes from a cursory review:

  • Most of those scripts only check for the steward group, which is active on all wikis anyway, so this will not change anything.
  • There are also many that check for groups that don't exist, like otrs-member or Global_rollback, because they were renamed. This is another reason why you should check for user rights, and not groups, as we don't rename rights for cosmetic reasons.
  • There are a few where this change will actually fix a bug – for example: https://www.mediawiki.org/w/index.php?title=User:Dragoniez/Gadget-MarkBLocked.js&oldid=5839421#L-160 This script would have previously not worked if you were a member of a global group that granted you the 'apihighlimits' rights, but which wasn't active on the current wiki. Another reason why you should check for user rights, and not groups.
  • There's at least one script where the previous behavior was more correct – https://meta.wikimedia.org/w/index.php?title=User:Perhelion/userstatus.js&oldid=20032725#L-1466 should probably display all global user groups, but now it will only display the active global user groups when viewing your own user page. (I guess it's arguable which behavior is more helpful.)

Overall, this seems unlikely to cause any disruption.

matmarex updated the task description. (Show Details)