Page MenuHomePhabricator

Replace Block::prevents with setters, getters and method that calculates the block's effects
Closed, ResolvedPublic

Description

Block::prevents is used in several different ways:

  1. It is used to calculate whether a block prevents the user from executing certain rights. It does this with a mixture of hard-coding, getting the properties of a Block, and possibly overriding based on global configs. It is also used to calculate whether a block prevents the user from editing their own talk page, using 'editownusertalk', which does not appear in any list of rights, but is a string passed into Block::prevents when needed
  2. It is used to set Boolean block properties corresponding to ipb_create_account, ipb_block_email and ipb_allow_usertalk. Confusingly, it does not always return the same value that it set, because of (1)
  3. It is used to get the above listed properties; however, because of (1), it does not always get the actual property. One example of where this could be a problem is in SpecialBlock::processForm, when updating an existing block. Flags set by default on the new block can be different from the old block due to how global configs interact with the old block's flags, even though the user performing the block didn't intentionally change them. This will be a problem if the global configs are ever altered after the block is updated.

Block::prevents could be split out into:

  • get/setters for the Boolean flags
  • a method for determining whether the user is blocked from their own user talk page
  • a method for determining whether a right is blocked, which would do most of what Block::prevents currently does, except for the above points

Once we separate these methods, then in contexts where we are really interested in the properties set on the block, we can use the get/setters, and know that the return value reflects the database.

Event Timeline

Change 489662 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] WIP Separate out different functionalities of Block::prevents

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

This also explains why a block's entries in the logs at Special:Block/<BlockedUser> and Special:BlockList are sometimes different. The former is created at the time when the block is originally submitted, so it reflects the block flags in the database. But the latter is dynamically generated, meaning that it has to represent how the block behaves, because of the lack of a mechanism for getting the block properties without Block::prevents modifying them first. The form at Special:Block/<BlockedUser> is also dynamically generated, so it also has to reflect the block's behaviour, and contradicts the block log at the bottom of the page.

Change 489662 merged by jenkins-bot:
[mediawiki/core@master] Separate out different functionalities of Block::prevents

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

@Tchanders If I create a block for $user and check "Account creation", if I go to Special:Block/$user "Account creation" is unchecked.

I checked that the BlockList shows "account creation disabled", and that in the database ipblocks row for that block as ipb_create_account=1.

This was on my local vm (MediaWiki 1.33.0-alpha (5696249) 13:58, 22 February 2019) as beta cluster is read-only atm.

I checked that this did not happen on test.wikipedia.org (e.g. https://test.wikipedia.org/wiki/Special:Block/The_Suix_Zero) (MediaWiki 1.33.0-wmf.18 (rMW6deca5eb7521) 20:11, 20 February 2019)

acc_creation_disabled_table.png (258×1 px, 18 KB)

acc_creation_disabled_checkbox.png (767×746 px, 41 KB)

@dom_walden Ah, nasty - looks like it's is a new bug introduced by: T208510, merged not long before this. The JavaScript unchecks the checkbox because it's a partial block (with JavaScript disabled, it is checked). Filed as T216845.

Change 492368 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/AbuseFilter@master] Replace calls to deprecated Block::prevents

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

Change 492370 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Replace calls to deprecated Block::prevents

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

Change 492376 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/DisableAccount@master] Replace calls to deprecated Block::prevents

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

Change 492378 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/EventBus@master] Replace calls to deprecated Block::prevents

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

Change 492380 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/GlobalBlocking@master] Replace calls to deprecated Block::prevents

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

Change 492384 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/UserMerge@master] Replace calls to deprecated Block::prevents

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

Change 492378 merged by Ppchelko:
[mediawiki/extensions/EventBus@master] Replace calls to deprecated Block::prevents

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

Change 492368 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Replace calls to deprecated Block::prevents

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

Change 492747 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Remove Target/User validation from Block::appliesToUsertalk()

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

Change 492747 merged by jenkins-bot:
[mediawiki/core@master] Remove Target/User validation from Block::appliesToUsertalk()

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

Change 493110 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/BlueSpiceUserManager@master] Replace calls to deprecated Block::prevents

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

Change 493115 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/RegexBlock@master] Replace calls to deprecated Block::prevents

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

As mentioned in T214508, I was worried about regressions around editing user_talk while blocked, so here is a spreadsheet showing the outcome of a users attempting to edit their user_talk page. Each user in each row has a different combination of block parameters, and each IP address they are editing from (one in each column) has a different combination of block parameters as well. The second sheet shows the parameters for each username and IP block.

Using conditional formatting as a blink oracle, I can see that the outcome of the users' actions don't change when they do it from a different IP.

MediaWiki 1.33.0-alpha (f8efd21) 12:17, 26 February 2019

I am wondering now whether I should test (some of) the extensions which have been patched as part of this task.

I am wondering now whether I should test (some of) the extensions which have been patched as part of this task.

I note that 4 of the extensions modified above are used in enwp, so I briefly tested 3 out of 4 of them (could not test the last one, see below).

GlobalBlocking:
Quickly checked that global blocks still effective and blocked users from user talk and account creation.
Version: (37dd01c) 17:54, 2 March 2019

CheckUser:
Mass block appears capable of blocking a user, incl. talk page and not email if blocking user does not have rights.
Version: 2.4 (9f74efc) 21:17, 3 March 2019

UserMerge:
Merged two users who both had (partial) blocks. It chose one block over the other.
Version: 1.10.1 (4787d6e) 08:48, 25 February 2019

EventBus:
Attempted to use it via test.wiki, but could not work out the endpoint or access the log https://wikitech.wikimedia.org/wiki/Kafka_Job_Queue#Logs. Did not attempt to install locally as it looks quite involved, and I am not sure it is worth the time considering the commit is relatively minor.

All tested on MediaWiki 1.33.0-alpha (ffb2ab7) 05:29, 4 March 2019.

Please return this to the QA column if you would like anymore testing done.

Thanks @dom_walden - I'll leave it to @TBolliger and/or any extension maintainers to request more testing

@dom_walden — Of all these extensions and your comments, I think CheckUser is the one that could benefit from some additional testing of both Sitewide and Partial Blocks.

Thank you for being so thorough with your notes!

Change 492376 merged by jenkins-bot:
[mediawiki/extensions/DisableAccount@master] Replace calls to deprecated Block::prevents

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

Change 492370 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Replace calls to deprecated Block::prevents

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

Change 492380 merged by jenkins-bot:
[mediawiki/extensions/GlobalBlocking@master] Replace calls to deprecated Block::prevents

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

Change 493115 merged by jenkins-bot:
[mediawiki/extensions/RegexBlock@master] Replace calls to deprecated Block::prevents

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

Change 492384 merged by jenkins-bot:
[mediawiki/extensions/UserMerge@master] Replace calls to deprecated Block::prevents

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

CheckUser:

After searching for username or IP, it allows you to block a single user or IP by sending you to the URL Special:Block/$user. I did not test this.

You can mass block users after you have found them by IP by posting a list of their usernames. This is a sitewide, autoblock block (no option) but you can choose to block users from sending email and their user talk. I checked that these were applied in the database and were effective in the UI when logged in as those users. Also checked that the autoblock was applied to the last IP the user used (and had the same parameters except duration and email block).

Cannot mass block IPs, that I could see.

If you search for the edits of a blocking user/IP, the block appears in the list with the correct parameters reported.

No apparent way to edit blocks via CheckUser. If you mass block users, any users who are already blocked have their current block left untouched.

I believe this covers all the relevant functionality of CheckUser, unless I have missed something.

I also checked that the page Special:CheckUser was not blocked for someone with a partial block.

CheckUser:

After searching for username or IP, it allows you to block a single user or IP by sending you to the URL Special:Block/$user. I did not test this.

You can mass block users after you have found them by IP by posting a list of their usernames. This is a sitewide, autoblock block (no option) but you can choose to block users from sending email and their user talk. I checked that these were applied in the database and were effective in the UI when logged in as those users. Also checked that the autoblock was applied to the last IP the user used (and had the same parameters except duration and email block).

Cannot mass block IPs, that I could see.

If you search for the edits of a blocking user/IP, the block appears in the list with the correct parameters reported.

No apparent way to edit blocks via CheckUser. If you mass block users, any users who are already blocked have their current block left untouched.

I believe this covers all the relevant functionality of CheckUser, unless I have missed something.

I also checked that the page Special:CheckUser was not blocked for someone with a partial block.

This all sounds good. I think the only other defect in the past related to CheckUser was T208523: Blocks log entries display as malformed on Special:CheckUser which was fixed a few months ago.

Change 493110 merged by jenkins-bot:
[mediawiki/extensions/BlueSpiceUserManager@master] Replace calls to deprecated Block::prevents

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