Page MenuHomePhabricator

Overlapping blocks may display incorrect block notice
Closed, ResolvedPublic3 Story Points

Description

Problem

When T206163: Restrictions of overlapping blocks should be merged on enforcement is complete, the restrictions on overlapping partial blocks will be merged together and the user could get a block notice for a block that doesn't cover the restriction.

This can cause confusion if the user wants to know why they are blocked from a page, because they wont be able to specify which block it was that caused them to not be able to edit.

Example

User has two blocks that are applied to them (ip ranges, etc.) one for Saturn and another for Mars. The first block selected is the one for Saturn but they are trying to edit Mars. The user will be prevented from editing, but the block notice that is displayed will be for the block that applies to Saturn

Proposed solution

Improve the message shown to the user by including:

  • The block ID(s), if we have any
  • Show the expiry (last expiry from all the blocks) T225748
  • Show the reason (if we can) T225748

We should also ensure the information appears legibly on mobile.

Event Timeline

dbarratt created this task.Dec 19 2018, 6:22 PM
Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptDec 19 2018, 6:22 PM
TBolliger triaged this task as Low priority.Dec 19 2018, 6:34 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.
TBolliger added a subscriber: TBolliger.

This is not that important to fix. The important work is T206163.

Niharika raised the priority of this task from Low to Normal.Jun 4 2019, 4:39 PM
Niharika added a project: Anti-Harassment.
Niharika moved this task from Backlog to Cards ready to be discussed on the Anti-Harassment board.

From the estimation meeting:

  • Add the block IDs
  • Make sure it looks fine on mobile
  • Show the expiry (last expiry from the blocks)
  • Show the reason (if we can)
Niharika set the point value for this task to 3.Jun 13 2019, 7:00 PM

I notice on test.wikipedia.org, when there is a composite block blocking email, Special:EmailUser includes: "Block ID #".

This wasn't the case on beta.

@Niharika Should this be fixed as part of this bug, or raise a separate one?

@dom_walden We can fix it as part of this. The block ID should only be shown when we have an ID to show them. I'll update the ticket description.

Niharika updated the task description. (Show Details)Jun 20 2019, 4:30 PM
Tchanders moved this task from Ready to In Progress on the Anti-Harassment (The Letter Song) board.

I notice on test.wikipedia.org, when there is a composite block blocking email, Special:EmailUser includes: "Block ID #".


This wasn't the case on beta.
@Niharika Should this be fixed as part of this bug, or raise a separate one?

On Special:EmailUser, the message is customized depending on whether the block is partial or sitewide. I would guess that the block error looked different on beta because it was a sitewide block. The above screenshot shows the partial block error; the sitewide block error looks like this (note that there is an empty ID in the paragraph at the end):

The email error is actually a bit tricky to fix, because it bypasses the method that returns a customized message per block type (i.e. DatabaseBlock, SystemBlock, etc - for details see T227174).

We can report any relevant IDs for CompositeBlocks in cases where the message is customized by the block type. @Niharika do you think we could we scope this task to these messages? This includes desktop editing but not email, account creation, mobile editing, or anything else that uses the API.

I think it would be good to fix all these error messages, but it could require some work - filed as T227174.

Change 520479 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Report more information about composite blocks in block error messages

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

Tchanders updated the task description. (Show Details)Jul 10 2019, 7:13 PM

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.

Composite blocks can be made up of DatabaseBlocks (which have IDs) and/or SystemBlocks (which don't). The messages account for the following situations (note 3rd bullet point in each block notice):

  • There are multiple IDs to show (meaning there are multiple DatabaseBlocks; there may or may not be SystemBlocks too)

  • There is 1 ID to show (meaning there is one DatabaseBlock and at least one SystemBlock)

  • There are no IDs to show (meaning there are no DatabaseBlocks and multiple SystemBlocks)

Doing it this way prioritises giving details about the database blocks over giving details about the system blocks here. Block IDs are useful, because they allow a user to look up the precise details of the block, at Special:BlockList.

We could give more details about the system blocks, but there is no block to look up. A system block is defined by its type, and each type is associated with a reason, stored as a message, which is probably the most useful information we could give. However, including several reasons could make for a long block error message. (One example of a system block reason: "Your IP address has been blocked because it is an open proxy. Please contact your Internet service provider or technical support of your organization and inform them of this serious security problem.")

@Niharika What do you think of these messages?

@Tchanders This looks great. Way better than what we have at the moment. Is there a possibility to link to the relevant blocks when we have the Block ID from a DatabaseBlock? The point being that it would potentially allow them to repeal the block (Seeing who blocked them, going to their talk page etc) if they got blocked as collateral or something.

Another thing, can we verify if they show up somewhat okay on mobile or should that be another task?

Is there a possibility to link to the relevant blocks when we have the Block ID from a DatabaseBlock?

Linking to the IP address should list all of the blocks against it (including the ranges):
https://test.wikipedia.org/wiki/Special:BlockList?wpTarget=92.40.248.2

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?

dbarratt added a comment.EditedJul 10 2019, 11:32 PM

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?

Alternatively, I suppose we could drop the ids from the block message, but that feels... idk less helpful?

Then again, there isn't a way to access the block by block id (really? that seems wrong?), everything is done by target:
https://test.wikipedia.org/wiki/Special:Block/92.40.248.0/23

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?

It is possible to filter Special:BlockList by block ID, by entering #<ID> into the target field, or passing #<ID> in as the wpTarget URL param:

This is explained on English Wikipedia at https://en.wikipedia.org/wiki/Special:BlockList using the message blocklist-summary (see: https://en.wikipedia.org/wiki/MediaWiki:Blocklist-summary), but I'm not sure why this message is customized per-wiki.

Is there a possibility to link to the relevant blocks when we have the Block ID from a DatabaseBlock?

@Niharika The block ID is currently not a link on the single block message either:

Since the error params are built in the same place, it might make sense to add these links to the block ID param in a separate task? (Incidentally, the mobile message does link to Special:BlockList, with the ID filter added - see T225748#5261788)

Another thing, can we verify if they show up somewhat okay on mobile or should that be another task?

This change won't affect mobile since the mobile block notice is built independently, but I think it should be fixed in a separate task. (There's more technical detail about this on T227174.)

Here's the mobile block message task: T225939

Oh ok, I probably added the link to the block id on mobile and that's what I was thinking of.

@Niharika How do you want to proceed? Is what @Tchanders has now resolve this task?

Is there a possibility to link to the relevant blocks when we have the Block ID from a DatabaseBlock?

@Niharika The block ID is currently not a link on the single block message either:


Since the error params are built in the same place, it might make sense to add these links to the block ID param in a separate task? (Incidentally, the mobile message does link to Special:BlockList, with the ID filter added - see T225748#5261788)

Sounds good, we can have another task for that.

Another thing, can we verify if they show up somewhat okay on mobile or should that be another task?

This change won't affect mobile since the mobile block notice is built independently, but I think it should be fixed in a separate task. (There's more technical detail about this on T227174.)

👍

Change 520479 merged by jenkins-bot:
[mediawiki/core@master] Report more information about composite blocks in block error messages

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

Tested various combinations of database and system blocks. Behaviour is as Thalia describes above (T212326#5322341).

Tried various places block messages appear. The change appears to only affect the message you see when editing a blocked page.

Block messages on VisualEditor also reflect change.

API and Mobile block messages are unchanged.

(There is a bug affecting block messages on MobileFrontend - T228736 - so had roll back to an earlier version).

I also combined database and system blocks with blocks set by TorBlock and GlobalBlocking extensions. The error messages generated by those extensions are separate from those generated by core.

Tested with blocked users with a couple of different non-default interface languages (fr and de).

Where possible, checked the logs for any errors. Did not see any.

dbarratt closed this task as Resolved.Jul 24 2019, 2:30 PM