@Niharika Not that I'm aware of, it just came up in code review because of the messages

@Niharika @dbarratt I have a question about how to display the list when there are a mix of local and global namespaces in the block.

@Niharika @dmaza There are a few places where the acceptance criteria don't match the behaviour of the patch (PS20). I suspect in some cases the acceptance criteria might just be old, so commenting here instead of in code review.

Steps to trigger the bug (needs $wgCookieSetOnAutoblock = true):

It seems worth fixing, since the block message will be more informative. In theory this problem could also arise in other ways; at the moment, autoblocks are only filtered out if they are found in the same database request as their parent block.

@dom_walden I think this bug probably doesn't cover these problems, since they both apply to the existing SystemBlock messages too. However, they should be fixed. Filed as: T225939

Thanks for reporting. It looks like it has been this way for a while (e.g. rolling back to 1.33.0, before the refactoring). @Niharika @SPoore would you have any concerns about allowing a user who is blocked from sending email to change their email address?

For testing/reviewing, this change affects:

• the error shown on trying to edit a page if at least one of the blocks applies to that page
• the error shown on Special:EmailUser if at least one of the blocks prevents email

@A2093064 The broken appearance of the page seems to be down to the MediaWiki:Group-sysop.js script.

(Didn't mean to remove the points value there, but since I did, replacing with something more accurate...)

I notice that I do see the link if I am an admin user who is blocked, even though being blocked means I cannot use Special:Block. I am assuming this is not a major problem.

In T207893#5251961, @dbarratt wrote:

In T207893#5250838, @Addshore wrote:

So I guess we use BlockManager to get the blocks of a user?

You can use either User::getBlock() or BlockManager::getUserBlock(). They are slightly different, but for your purposes, it should always return the same result.

@dmaza, @dbarratt and I have discussed separating the cookie blocking service from the BlockManager. @daniel do you have an opinion on this?

@A2093064 Thanks for the screenshot.

@Reedy Yes, that test should only be 1.33+

I can't remember if we said we'd split this up, but if so then the tagging is already filed as T221444

@Mooeypoo @dmaza @dbarratt As discussed, MultipleBlock might be too easily confused with the concept of storing multiple blocks against exactly the same target; whereas this work is about enforcing (but not storing) multiple blocks against different targets that all apply to a given user.

(I had a quick check that it does allow a logged-in user to create an account if the block allows account creation)

@dom_walden It turns out that is intentional, according to: https://github.com/wikimedia/mediawiki/blob/master/includes/user/User.php#L4377 - I can't find it documented anywhere else.

We could display an error message, but if we do that then we should try to be consistent across all forms, ie always be prepared to handle submission of forms that haven't loaded properly.

Thanks @Jdforrester-WMF and @Umherirrender. The extensions that document @param Block, @var Block and @return Block should now have patches updating all their references to Block, tagged with this task.

We can update the affected extensions.

AuthManager is calling BlockManager::isDnsBlacklisted directly, independently of checking the user's block. This leads to some odd effects:
(1) An unblocked user with the 'ipblock-exempt' right can still be blocked from creating an account from an affected IP, even though they will be unaffected by the block otherwise.
(2) As @dom_walden points out, DNS blacklisted IPs get special treatment, whereas proxy list IPs don't.

@dom_walden Thanks for reporting these - they should be fixed now.

What @dbarratt is describing is similar to how Special:Preferences currently works: you arrive at Special:Preferences with the current state and a disabled "Save" button. If you change the state, the "Save" button is enabled, signalling that you've made a change.

@dom_walden I agree - filed as T224468

Reopening because the checklist isn't complete