| Tchanders | |
| Jan 23 2019, 7:05 PM |
| F28006964: Screen Shot 2019-01-23 at 11.50.50 AM.png | |
| Jan 23 2019, 7:52 PM |
Special:BlockList is not currently aware of the rules surrounding whether a blocked user can edit their own user talk page, so sometimes displays this incorrectly.
Special:BlockList is looking for the config flag, which should be ignored on Partial Blocks
The logic to determine whether a partial block allows a user to edit their own user talk page is currently executed in User::isBlockedFrom, at the point when the user attempts to edit their talk page. In order to make the block list correct, we'd either have to duplicate that logic when parsing the blocks for the block list, or move it to when the block is saved, and store it in the ipb_allow_usertalk flag rather than ignoring the flag for partial blocks, as discussed in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/477447/. I'm in favour of the second way, since it's more universal.
Change 488533 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] WIP Use Block::prevents to check if a user can edit their talk page
Change 489662 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] WIP Separate out different functionalities of Block::prevents
Change 488533 abandoned by Tchanders:
Use Block::prevents to check if a user can edit their talk page
Reason:
Took the approach of separating out Block::prevents into methods that get/set block properties and methods that check block behaviour: I0e1316964192113190
Change 489662 merged by jenkins-bot:
[mediawiki/core@master] Separate out different functionalities of Block::prevents
The approach of making the ipb_allow_usertalk flag match the behaviour was abandoned (https://gerrit.wikimedia.org/r/488533) in favour of decoupling the block flags/logs/form on the one hand from the block's behaviour on the other hand (https://gerrit.wikimedia.org/r/489662).
Notes for QA
Once a block has been made to the user BlockedUser, there are various ways to "look" at the block - Special:Log?type=block, Special:BlockList, and Special:Block/BlockedUser
There are various Boolean flags set on the block (in addition to whether the block is sitewide and which pages/namespaces are blocked). These correspond to checkboxes on the form, e.g. "Account creation", "Editing their own talk page", etc, and should appear in the block log and block list.
There are various global configs on a wiki that can override these flags. E.g. the flag on a block could say that the user can edit their own user talk page, but a global config can override this and say that no blocked users can edit their own talk pages.
Before https://gerrit.wikimedia.org/r/489662, the block log would indicate what the flags on the block say, but Special:BlockList and Special:Block/BlockedUser would indicate how the block behaves, taking into account the global config settings.
After the patch, the logs should now be consistent with each other. So for example, if the "Editing their own talk page" checkbox is checked in the Special:Block/BlockedUser form, then the block's entries in the block log and the block list should both say "cannot edit own talk page". However, they may not be consistent with how the block actually behaves.
Some UI notes
There is now no longer anything logging how the block actually behaves. We could change Special:BlockList to do this, and include a note that this is describing the behaviour of the block on enforcement, not the stored features of the block?
For wikis where $wgBlockAllowsUTEdit is false, the checkbox for preventing a user from editing their own talk page is hidden, and the block will be stored with the flag set to false, as if the checkbox were unchecked. This is similar to the checkboxes for suppressing a user or disabling email, which act as if they were unchecked if they are hidden. This means that the block flag will indicate that the user can edit their own talk page, but in fact they can't, because when the behaviour of the block is checked, $wgBlockAllowsUTEdit will override the block flag. It means also that the logs won't indicate that the user is unable to edit their own user talk page. After T212391 the checkbox should be visible, disabled and checked, meaning that on submission, the flag will be set to say the user is blocked from editing their own talk page, and all the logs will reflect this.
@Tchanders If an IP is blocked (and is not anonymous, i.e. "Prevent logged-in users from editing from this IP address" is checked) and a logged in user with that IP address tries to edit their user_talk they see:
Internal error [bf889c7ad828d4f601c582c9] 2019-02-25 16:06:31: Fatal exception of type "InvalidArgumentException"
In the debug logs for the server:
[exception] [3a7e4b7c78f70c78b2b24566] /core/index.php?title=User_talk:Adam&action=edit InvalidArgumentException from line 1945 of /var/www/html/core/includes/Block.php: $usertalk must be a talk page for the block target
I think that code was added in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/489662/
Tested on local VM MediaWiki 1.33.0-alpha (ecbe578) 02:45, 25 February 2019.
It didn't seem to matter how the block was configured, other than not being anonymous. Did not see same problem with username blocks. Did not try IP ranges.
@dom_walden Thanks for finding that so quickly - it should be fixed by this: https://gerrit.wikimedia.org/r/492747
I programmatically generated as many combinations of blocks that I could think of via the API, for users and IPs.
I imported the data in Special:Log?type=block and Special:BlockList into a spreadsheet and checked that the "cannot edit own talk page" was (not) stated correctly for each block (depending on the value of ipb_allow_usertalk).
EDIT: And for a sample of Special:Block/$username I checked that the "Editing own talk page" was (un)checked as appropriate.
The bug from T214508#4981423 no longer occurs. Just in case, I am systematically attempting to edit (via the API) the user_talk of each blocked username from each blocked IP. It might take a while. I will report in T211578 (probably). EDIT: So far I have not seen anything that looks like a problem, nor any exceptions in the server logs.
Otherwise, I don't have anymore work to do for this bug specifically.