See T355286#9471626 for one use case; another use case is for WMF-office actions of global bans.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T359116 Split up CentralAuth into smaller extensions | |||
| Open | None | T373388 Merge CentralAuth locks into GlobalBlocking | |||
| Open | Feature | None | T355385 Allow marking global blocks not disablable by local wiki |
Event Timeline
Comment Actions
I don't see how. Locking is always available for a "superprotect". Stopping users from appealing anywhere but meta seems much preferable to locking.
Comment Actions
See parent task - it will replace current usages of locks for e.g. WMF banned users, since CentralAuth will no longer have a lock feature.
Currently local wikis already can not opt out global locks.
I will suggest a highly-restrictive of usage of such instead. See https://meta.wikimedia.org/wiki/Requests_for_comment/Global_account_blocking_practices#c-GZWDer-20240826114100-Discussion
Comment Actions
I would argue that this isn't the case, primarily from the point of view that this would be an option present for the stewards to use (and not the WMF) in all but a rare case. The WMF would only use it in the case of WMF global bans, which are rare. Plus the WMF can already do this through a global lock (which is why this task needs to be done to merge locking into global blocking).