In T208895#4726284, @TBolliger wrote:

Correct me if I'm wrong, but Wikimedia wikis do not use this functionality.

There are a few that do:
https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/InitialiseSettings.php$8286

It was enabled in T55871 and T74589

Still low priority. I assume it'll be an easy fix., but no rush.

This is arguably working as intended. I would agree this is low priority.

In T208895#4726402, @dmaza wrote:

This is arguably working as intended. I would agree this is low priority.

If you have the config enable, then creating a partial block on someone would cause them to not be able to log in, which sounds extreme when your only intention is to block them from editing a single page.

In T208895#4730270, @dbarratt wrote:

In T208895#4726402, @dmaza wrote:

This is arguably working as intended. I would agree this is low priority.

If you have the config enable, then creating a partial block on someone would cause them to not be able to log in, which sounds extreme when your only intention is to block them from editing a single page.

I agree it might be extreme but the flag doesn't specify anything different so technically it is not broken

It seems to fall into the same class as our other discussion about isBlocked and sitewide. We've changed the whole paradigm so we have to have a more holistic view of what the desired outcomes are and not just what this small block of code does.

I think the priority is low here and that we should seek some other input from those communities that use this config setting.

Yes, Lowest priority. I think we can probably walk away from this project and not touch this ticket at all.

In passing, during T209004, I have found a couple of uses which might need to be changed:

• https://gerrit.wikimedia.org/g/mediawiki/core/+/4a20209c8e3f34c2582d05202cc07c20d0a628c1/includes/auth/CheckBlocksSecondaryAuthenticationProvider.php#61
• https://gerrit.wikimedia.org/g/mediawiki/core/+/24778af34dac5fc937d617cce2b275176d9f7183/includes/mail/EmailNotification.php#227
• https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/5796d46565fd36740eee657a3686d757a8dde009/includes/Notifier.php#44
• Several places in Extension:OAuth

BlockDisablesLogin is used on private and fishbowl wikis (otrswiki, officewiki, …). They grant no rights to anons (except for fishbowls chapter wikis and foundationwiki, which do allow reading). In particular, they disallow signup. Blocks are meant to approximate account removal there. For example, after the term for a role like CheckUser or Steward expires, or after a chapter member leaves.

I presume that a partial block used by admins on such wiki today, would not apply a partial block but instead block the user site-wide and revoke their ability to login. Assuming partial blocks will be enabled by default eventually, this represents technical debt, and arguably a regression. It seems easy to mitigate without major changes, though:

1. We could toggle the partial block feature off if BlockDisablesLogin is in use. This is the simplest option. No special support, keeps it like it is today.
2. We could inform admins through the Special:Block interface (if BlockDisablesLogin is on), that attempting to use partial blocks will also block the target sitewide, and revoke their ability to log in. This would documents today's accidental state.
3. We could update BlockDisablesLogin code to check Block->isSitewide instead of getBlock. As @aezell mentioned, this is similar to what we've done past months with other features that could previously assume a block to be site-wide.

In T208895#5126405, @Krinkle wrote:

3. We could update BlockDisablesLogin code to check Block->isSitewide instead of getBlock. As @aezell mentioned, this is similar to what we've done past months with other features that could previously assume a block to be site-wide.

I think this is the best option, however, we need to figure out a way to message to the user of Special:Block what is happening. Perhaps there is pseudo option represented as a checkbox at the top of the form that is "Prevent Login" that disables the "Editing" section (and all other options for that matter). If the user unchecks the checkbox, the user is forced into an Editing block that is partial (the "Sitewide" option would be disabled).

Does that make sense?

This would be similar to the solution for T219931.

@dbarratt @Krinkle I notice that if $wgBlockDisablesLogin = true and the user's IP is blocked (but not the username) they are prevented from sending emails, even if the IP block does not apply to emails.

I think the issue is around https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/includes/user/User.php#3426. This removes rights from a user if they have any blocks, including IP/range blocks. But, I think $wgBlockDisablesLogin is only supposed to apply to username blocks.

Should this be dealt with here, or raise a separate ticket?

In T208895#5281210, @dom_walden wrote:

@dbarratt @Krinkle I notice that if $wgBlockDisablesLogin = true and the user's IP is blocked (but not the username) they are prevented from sending emails, even if the IP block does not apply to emails.

I think the issue is around https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/includes/user/User.php#3426. This removes rights from a user if they have any blocks, including IP/range blocks. But, I think $wgBlockDisablesLogin is only supposed to apply to username blocks.

Should this be dealt with here, or raise a separate ticket?

Uhh... a separate ticket please. :)

Change 824142 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/core@master] [WIP] Do not check for IP blocks in testUserForCreation()

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

Change 824142 merged by jenkins-bot:

[mediawiki/core@master] Fix block handling in CheckBlocksSecondaryAuthenticationProvider

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