@Niharika Not that I'm aware of, it just came up in code review because of the messages
Sat, Jun 22
@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.
Fri, Jun 21
Thu, Jun 20
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.
Tue, Jun 18
Mon, Jun 17
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?
Sat, Jun 15
Fri, Jun 14
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
Thu, Jun 13
@A2093064 The broken appearance of the page seems to be down to the MediaWiki:Group-sysop.js script.
Wed, Jun 12
(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.
Tue, Jun 11
Mon, Jun 10
Fri, Jun 7
@A2093064 Thanks for the screenshot.
Thu, Jun 6
@Reedy Yes, that test should only be 1.33+
Wed, Jun 5
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.
Tue, Jun 4
Mon, Jun 3
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.
Fri, May 31
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.
Thu, May 30
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.
Wed, May 29
@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.
Tue, May 28
May 24 2019
Reopening because the checklist isn't complete