Wed, Aug 14
@Niharika How important do you think it is to fix this?
Fri, Aug 2
@dbarratt You can this locally by enabling TorBlock, setting $wgTorDisableAdminBlocks = true and overriding TorExitNodes::isExitNode() to return true/false. It should then remove any non-user blocks, but keep any user blocks or composite blocks that contain user blocks.
Thu, Aug 1
Wed, Jul 31
Mon, Jul 29
Thu, Jul 25
Wed, Jul 24
Mon, Jul 22
Example for reviewing/testing/product input
Jul 18 2019
Jul 16 2019
@Krinkle Good to know for next time.
Jul 15 2019
- The enableAutoblock widget is selected by default. Before the fix, it is still selected when hidden, and still therefore selected when it reappears. (The PHP knows to ignore it if the target is not of the correct type.) After the fix, it should not be selected when disabled, since this misleadingly implies that autoblocks will be enabled. However, when it is re-enabled it will still be unchecked. If this needs to be fixed, we might need to do something similar to the "Account creation" checkbox (T208510).
This applies to all the checkboxes. [...]
Jul 12 2019
Thanks for the examples - we could try to address this while working on block error messages.
Jul 11 2019
Here's the mobile block message task: T225939
I just realized that that page does not list the block id. :/ I wonder if it would be wise to add it to the BlockList and make that a url parameter?
Jul 10 2019
Here are some screenshots of the block notice shown on trying to edit an article on desktop, after https://gerrit.wikimedia.org/r/520479. It now shows any relevant block IDs.
@RhinosF1 Thanks for the screenshots. It looks like the site is using MediaWiki version 1.33.0 (https://publictestwiki.com/wiki/Special:Version) - we fixed the checkbox to become disabled since then in T224032.
With JS, a number of checkboxes become disabled depending on the block parameters entered in the form. Obviously this doesn't happen without JS, which can make the experience misleading (e.g. T227199#5321559).
Jul 9 2019
@Jdlrobson Yes that should fix this - it hasn't been deployed yet, which is why the errors are still being logged.
Jul 3 2019
There's a fix in master: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/519177/ It was tagged with T180050, which this task seems to duplicate (see above). Do you think we should backport that commit?
@Krinkle Thanks for the verbosity.
Jul 2 2019
Jul 1 2019
Jun 28 2019
This is similar to T180050. The problem is here:
Jun 27 2019
Jun 26 2019
Jun 25 2019
@Niharika Not that I'm aware of, it just came up in code review because of the messages
Jun 22 2019
@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.
Jun 21 2019
Jun 20 2019
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.
Jun 18 2019
Jun 17 2019
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?
Jun 15 2019
Jun 14 2019
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
Jun 13 2019
@A2093064 The broken appearance of the page seems to be down to the MediaWiki:Group-sysop.js script.
Jun 12 2019
(Didn't mean to remove the points value there, but since I did, replacing with something more accurate...)