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)

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.

In T212326#5270394, @dom_walden wrote:

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

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?

In T212326#5322380, @Niharika wrote:

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?

In T212326#5322894, @dbarratt wrote:

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?

In T212326#5324492, @Tchanders wrote:

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.