Change 507732 had a related patch set uploaded (by Zoranzoki21; owner: Zoranzoki21):
[mediawiki/core@master] Disable a user session and log them out when blocking

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

In T222281#5151702, @gerritbot wrote:

Change 507732 had a related patch set uploaded (by Zoranzoki21; owner: Zoranzoki21):
[mediawiki/core@master] Disable a user session and log them out when blocking

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

I made patch and help with improvements is welcome. :)

Copying over the "in-patch" comment for better discussion

I think that this new feature should be behind a flag and/or as another option for the admin to check when creating the block.

Blocks are not always sitewide and logging out a user when creating a partial block (editing or otherwise) doesn't make much sense considering that the user can still perform other actions and/or keep editing other pages/namespaces

A checkbox in SpecialBlock behind a config flag would be the way to go imo. Said checkbox should probably be disabled for partial blocks considering that it doens't make much sense to provide such functionality in that particular case.

Change 507732 abandoned by Zoranzoki21:
Disable a user session and log them out when blocking

Reason:
No, I am not feeling sure and I no want to work on this

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

In T222281#5151753, @dmaza wrote:

Copying over the "in-patch" comment for better discussion

I think that this new feature should be behind a flag and/or as another option for the admin to check when creating the block.

Blocks are not always sitewide and logging out a user when creating a partial block (editing or otherwise) doesn't make much sense considering that the user can still perform other actions and/or keep editing other pages/namespaces

A checkbox in SpecialBlock behind a config flag would be the way to go imo. Said checkbox should probably be disabled for partial blocks considering that it doens't make much sense to provide such functionality in that particular case.

i did say feature flag originally ;)

But yeah, I agree. It has some use for some types of blocks (indef block of everything), and on some types of wikis (like wikitech where blocks are more used for bad actors/spammers etc, rather than things like edit warring). But it definitely shouldn’t just be done unconditionally for all blocks

i did say feature flag originally ;)

You did, sorry I missed it :)

we want to kill of their sessions and log them out
because requesting unblock isn't a rule on the wiki...
because they aren't allowed to edit their talk page,

If you need all these, there's no reason to not use $wgBlockDisablesLogin = true

IMO the correct way to do it:

• Add Block::isLoginBlocked() which in the default implementation just checks $wgBlockDisablesLogin and whether the block is sitewide.
• Replace all outside uses of $wgBlockDisablesLogin with this new method.
• Add a "lock" checkbox to the GlobalBlocking block form once T17294: Allow globally blocking of accounts is done. (Maybe the core one too, but it's a feature in search of a use case.) Add a globalblocks.gb_lock field to store it in. Make sure SessionManager::invalidateSessionsForUser() is called when the checkbox is set.
• Replace all references to globaluser.gu_locked with globalblocks.gb_lock. This is the hard part; you need a join, need to think about query performance, there might be multiple blocks, partial blocks, blocks that apply via the IP etc. But it's not used much, mostly just to display things. Possibly can be replaced with a standard BlockManager-based lookup.
• Murder CentralAuth account locking code with extreme prejudice.

CentralAuth locks are per-user flags, this would be a per-block flag, so the semantics are pretty different, and arguably the per-user one makes more sense (it's unlikely that we'd want to lock someone out with an expiry, for example). But there is so much infrastructure for blocks that would be useful for locking but too much work to recreate, that it's probably a good change even despite that.

For usage in non-CentralAuth sites we may build a feature in MediaWiki core, but this (local) feature should be disabled if CentralAuth is installed (it may no sense to disable login of local SUL accounts).

BTW (not directly related to this task), the hidden and suppressed status of global accounts is stored in gu_hidden_level column (added in T297094) and is a per user flag; while local suppressed status (ipb_deleted) is per block. For the latter, see also T346716: Split user suppression/hiding (ipb_deleted) out of the ipblocks table.

In T222281#9233326, @Bugreporter wrote:

For usage in non-CentralAuth sites we may build a feature in MediaWiki core

Sure, I just mean, does anybody need that feature?

In T222281#9233386, @Tgr wrote:

In T222281#9233326, @Bugreporter wrote:

For usage in non-CentralAuth sites we may build a feature in MediaWiki core

Sure, I just mean, does anybody need that feature?

Since one usage of lock is to handle compromised accounts, such a feature also useful for 3rd party wikis (as an alternative of invalidate password and session, which requires shell access).