When global account blocks are enabled, Special:CentralAuth/<username> should display information about any global blocks on that specific account, as well as a link to block that user if the viewer has the permissions to do so.
Description
Details
Event Timeline
I suppose that would require some sort of hook for adding information snippets to Special:CentralAuth. At which point I wonder if we should rename it to something less extension-specific (like CentralUser)?
Currently there are two well-defined way to make relation between accounts of different wikis:
- $wgSharedDB - widely used, but does not support global login across primary domain, and user group can only be globally managed with some hack. (that page also provides a possibility to share ipblocks table to provide global blocks that can not coexists with local blocks, but we will soon have a proper way to make global blocks).
- CentralAuth - used in many wiki farms but not well documented or maintained enough to be recommended to be used generally. Provides a series of new features (central list of global users, global login, global locks, global user groups/wiki sets, global rename, etc.)
Both solutions provide a common central ID for users across wikis (central ID is a core MediaWiki concept, and by default is same as user id, but CentralAuth provides own central ID).
And potentially the third:
- A number of auth extensions (e.g. PluggableAuth based) can provide login to MediaWiki via 3rd-party accounts. If multiple wikis set up login to a common source, we de facto have a system of global accounts, though there would be not a global login (which require a SessionProvider implementation), not a central ID (which require a CentralIdLookup provider, and the only one currently is CentralAuth).
Therefore, An idea is we only keep global account relation and part of CentralAuth that directly require it (GlobalRename) in CentralAuth, and move tech-neutral component to its own extensions that does not depends on CentralAuth so that they can be used with shared tables (these features would only require central ID, which is provided by core):
- Global edit count to Extension:GlobalEditCounter
- Global lock to Extension:GlobalLocking (or even kill it as suggested by Tgr)
- Global user groups to Extension:GlobalUserGroup (task: T355381: Split global group and wiki set to a new extension)
- Global session to Extension:GlobalSession (spliting gu_auth_token of globaluser table to new table)
- Special:CentralAuth to Extension:CentralUserInfo (described in detail in this comment)
Now we consider how Special:CentralAuth will work after the split. First, it should receive a Central ID from a user name so you can use it with user name instead of central ID. The potentially methods are:
- Receive it from CentralAuth - this will no longer work if we make this special page independent of CentralAuth.
- First resolve it to a local account, then find its central ID - does not work when we does not have a local account (currently Special:CentralAuth supports using with unattached accounts).
- Add a new function to CentralIdLookup that resolves a (potentially not locally exist) user name to Central ID - conceptually we may support mapping completely different usernames in different wikis to the same central ID (though neither $wgSharedDB nor CentralAuth support so), so its semantic is unclear (I am not sure whether this should be supported)
- In Extension:CentralUserInfo provides a new hook to resolve a username so CentralAuth can implement it
Next the Central ID is used to receive multiple kinds of informations which will all be displayed in the special page (with the source and proposed component related listed after):
- Username - provided by parameter
- Registered - gu_registration in globaluser, will kept in CentralAuth
- Total edit count - currently by summing up edits in local wiki, but can use global_edit_count instead (will become GlobalEditCounter)
- Number of attached accounts - by checking localuser table
- Global group - global_user_groups table (will become GlobalUserGroup)
- If account is locked, link to CentralAuth in a central wiki
- Global account log snippet - by querying logging table by name
- List of local accounts - by checking localuser table and local wikis
If we want to design Special:CentralUserInfo to be non-CentralAuth dependent, it will contain:
- "Basic information" with an account name and hooks for other extensions to add new fields
- Global account log if relevant
- Hooks for other extensions to add sections, including GlobalBlocking in this task, and we need to consider how these sections be ordered
@Bugreporter I filed T359116: Split up CentralAuth into smaller extensions about splitting up CentralAuth.
If this is done, it would optimally also note in CentralAuth the projects that exempted a user from their global block.
Change #1055991 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[integration/config@master] [WIP] Zuul: [mediawiki/extensions/CentralAuth] Add GlobalBlocking dependency
The stewards would prefer that this task be completed sooner than later. As such, moving into the sprint. This will be useful for Temporary accounts, because stewards (and other users) will be able to see if a temporary account is globally blocked easily from Special:CentralAuth (which is often linked to for cross-wiki account management).
Change #1056991 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CentralAuth@master] [WIP] Add CentralAuthInfoFieldsHook
Change #1056990 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CentralAuth@master] SpecialCentralAuth: Allow info field label to already be a Message
Change #1057197 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/GlobalBlocking@master] [WIP] Display global block information on Special:CentralAuth
I've found a place for the links to go, but I am unsure of where we would display on which wikis is the global block disabled.
The links to globally block have been added into the "Global account information" to be similar to the "Locked" information. However, adding a list after this of the wikis where the block is disabled could become lengthy.
If the global block is disabled by more than a few local wikis, it should most likely be removed, so I wouldn't worry too much about the list becoming lengthy.
The added bullet in F56788229 seems fine. I'd also like to see the global block log - equivalent to the Previous global account changes (centralauth-admin-logsnippet) section for locks.
Change #1064832 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/GlobalBlocking@master] Make global block action links point to central wiki
Change #1064833 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/GlobalBlocking@master] Use GlobalBlockingLinkBuilder for central URL in GlobalBlockingHooks
Myself and @Dreamy_Jazz reviewed the current mockup and discussed how to display wikis exempt from global blocks.
- We agreed to add a table with exempt wikis underneath Global account information.
- “Wikis exempt from global block” will only show if at least one wiki has the global block disabled.
- Assuming it's not too much work, we will convert the page to OOUI (ideally it would be in Codex but this is not as straightforward. OOUI is one step closer towards Codex). See T122016: Convert Special:CentralAuth to use OOUI
- Converting to OOUI will improve the mobile interface.
- The "unmerge local accounts" table at the bottom of page will remain in the old UI as it contains table icons that have not yet been updated. (I will talk to Design System Team about converting these icons).
Below is a desktop mockup:
"Wiki exempt" table in this example is a Codex table so may output slightly differently
The mock is missing the existing Previous global account changes section that shows the lock/hide log and a section to show the global block log.
Change #1064832 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Make global block action links point to central wiki
Change #1067987 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/GlobalBlocking@master] Pass IContextSource to GlobalBlockingLinkBuilder::getActionLinks
Change #1064833 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Use GlobalBlockingLinkBuilder for central URL in GlobalBlockingHooks
Change #1067987 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Pass IContextSource to GlobalBlockingLinkBuilder::getActionLinks
Change #1056990 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] SpecialCentralAuth: Allow info field label to already be a Message
Thanks for raising that, I have added it to the mockup for completeness:
and a section to show the global block log
My understanding is that this is a feature request and @Dreamy_Jazz is intending to add it.
Change #1056991 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Add CentralAuthInfoFieldsHook
Change #1057197 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Display global block information on Special:CentralAuth
Change #1071832 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/CentralAuth@master] [WIP] Add Global block exempt list to Special:CentralAuth
Change #1055991 merged by jenkins-bot:
[integration/config@master] Zuul: [mediawiki/extensions/CentralAuth] Add GlobalBlocking dependency
Change #1074129 had a related patch set uploaded (by Majavah; author: Majavah):
[mediawiki/extensions/GlobalBlocking@master] Don't show empty global block details in Special:CA
Change #1074134 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/GlobalBlocking@master] Add tests for Ic55ebc74a320b18985200bc0edbb9e3829d42c2c
For QA, I would note that the final design changed from the mock listed in the task description. Notably:
- The "wikis exempt from global block" table uses the wikitext table styling and is a separate fieldset
- The reason field for the admin status form looks like Special:Block reason field.
Change #1074129 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Don't show empty global block details in Special:CA
Change #1074134 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Add tests for Ic55ebc74a320b18985200bc0edbb9e3829d42c2c
Change #1071832 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Add Global block exempt list to Special:CentralAuth
QA has been completed, and the new code changes are functioning as expected per the ticket description.