Page MenuHomePhabricator

Improve the consistency of block error notices
Closed, ResolvedPublic8 Story Points


There are many different situations in which a block error notice might be shown to a user, and the message is often different depending on the situation.

Error messages also differ depending on the features of the block. A few examples:

  • The desktop editing message differs according to the type of block (DatabaseBlock, SystemBlock, etc), whether the block is an autoblock, and whether it is partial/sitewide
  • The Special:EmailUser message differs according to whether the block is partial/sitewide
  • The Special:CreateAccount message differs according to whether the block is against an IP range or not

The message customization is ad hoc, and can be improved. In addition, some messages do not make sense and need fixing (e.g. T227110, T226990, T212326#5270394).

How block errors are made

Block errors are reported using a message key and formatted block details to pass in as message parameters.

AbstractBlock::getBlockErrorParams() returns an array of parameters, and AbstractBlock::getPermissionsError() adds an error message key to the array. The different block types use different message keys, which pass in different parameters. Additionally, ApiBlockInfoTrait::getDetails() returns an array of block error parameters, independently of AbstractBlock::getBlockErrorParams(). (These two methods each return a different set of parameters, so different information about the block is available in different situations.)

The information for the error message is built in the following different ways:

  1. Call AbstractBlock::getPermissionsError(), or throw a UserBlockedError, which calls AbstractBlock::getPermissionsError() (example: desktop editing)
  2. Call AbstractBlock::getBlockErrorParams() directly, and add a custom message key to the array (example: emailing)
  3. Get block error params from ApiBlockInfoTrait::getBlockDetails() and create a custom message (example: mobile editing)
  4. Get information about the block directly (e.g. by calling $block->getId(), $block->getReason(), etc) and create a custom message (example: account creation)
Making block errors more consistent

Thinking about long-term stability, it could be helpful if block message creation were more centralized. However, we should be careful to allow for flexibility and customization where appropriate.

Some ideas:

  • We could define a superset of details that can describe any block, and make sure that AbstractBlock::getErrorParams() and ApiBlockInfoTrait::getBlockDetails() get these from the same place. Messages could then choose which of these details to use.
  • We could try to re-route places where errors are built using (2) and (4) to use (1) and (3). E.g. we could restructure the block messages so that they always show the same details for a particular type of block (DatabaseBlock, SystemBlock, etc) - or no details at all where appropriate - and add a custom prefix (e.g. "You have been blocked from using email", "You have been blocked from creating an account", etc).
  • We could make some kind of formatting layer between the block object and the error. We could move AbstractBlock::getErrorParams() and AbstractBlock::getPermissionsError() to this layer, thus moving the context/language dependency out of blocks (and potentially addressing other language-related problems such as T227007).

  • Create a block error formatting service and move the logic for formatting error params and building the final error message array to this service
  • A method on the block classes returns a set of normalised, unformatted error params (e.g. as an associative array/object); the params should be consistent with a predefined interface
  • The service accepts a block object and some information about the context (perhaps a message key?) and builds an error message array based on these
Linked tasks:


Related Gerrit Patches:

Event Timeline

Tchanders created this task.Jul 3 2019, 8:51 AM
Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptJul 3 2019, 8:51 AM
dbarratt updated the task description. (Show Details)Jul 4 2019, 3:31 AM
dbarratt updated the task description. (Show Details)
JMinor added a subscriber: JMinor.Jul 16 2019, 8:33 PM
Mooeypoo set the point value for this task to 8.Jul 31 2019, 5:48 PM
Tchanders updated the task description. (Show Details)Jul 31 2019, 6:42 PM
Tchanders added subscribers: Mooeypoo, dbarratt, dmaza.
Niharika triaged this task as Normal priority.Aug 1 2019, 6:06 PM
JMinor added a comment.Aug 1 2019, 6:11 PM

Hey all, on the app side we're dealing with a fairly high and increasing volume of complaints/reviews/emails about blocks. In the mobile context many of our messages are too long, refer to specific desktop UI elements or are not user understandable. We'd like to help improve these in any way we can. In the propsoal to build this abstract service, for example, we would appreciate considering these issues in the abstraction and potentially providing a path to mobile, api and/or app specific strings. We'd also be willing/able to contibute design and product time to writing English strings which are more usable across clients.

In any case here's a few things we'd ask you to consider for mobile and app users:

  • Don't refer to specific UI elements ("click the button below") as the presentation context varies.
  • Provide some guidance on the cause of their block (esp IP blocks which hit mobile users hard and are difficult to understand)
  • Be concise.
  • Don't refer to specific wiki process ("contact an admin to ...") which may vary by language or UI context

Thanks for taking this on, and thanks for keeping our mobile users in mind.

JMinor added a subscriber: JoeWalsh.Aug 1 2019, 6:13 PM

@Niharika Given @JMinor's comment above, I think we should escalate the priority of this. Additionally, maybe we should make it the final focus of our Block work for now. Once we deliver this, we can pick up some other work and possibly come back to the remaining Block effort?

Tchanders claimed this task.Aug 1 2019, 7:29 PM
Tchanders moved this task from Ready to In Progress on the Anti-Harassment (The Letter Song) board.

Thanks for the helpful examples, @JMinor! We'll keep those in mind as we fix the block messages.

@Niharika Given @JMinor's comment above, I think we should escalate the priority of this. Additionally, maybe we should make it the final focus of our Block work for now. Once we deliver this, we can pick up some other work and possibly come back to the remaining Block effort?

I see Thalia already picked it up. This ticket is about creating the underlying service though and the actual fix for block messages will happen in the other related tickets (per my conversation with @Mooeypoo yesterday). Once this work is done, we can actually go in and fix the messages.
As for wrapping up the work on Blocks, I agree with you. I am going through Interaction Timeline backlog at the moment and will setup a meeting next week for the team to go over that project and prioritize tickets we want to estimate for it.

Change 528918 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] WIP Introduce a formatter service for block errors

Niharika updated the task description. (Show Details)Sep 30 2019, 10:22 PM
Niharika updated the task description. (Show Details)Sep 30 2019, 10:26 PM

Change 528918 merged by jenkins-bot:
[mediawiki/core@master] Introduce a formatter service for block errors

dom_walden added a subscriber: dom_walden.EditedOct 15 2019, 1:52 PM

@Tchanders @Niharika When I am blocked from Special:EmailUser with a composite block, I am seeing text like Block ID #Relevant block IDs: #10032, #10034 (your IP address may also be blacklisted)

Where at least one of the blocks is sitewide:

Where all the blocks are partial:

This possibly affects other places, although I have not seen it anywhere else yet. It looks like a couple of the json translation strings (in en.json, probably other languages) have block ID is #$5 or Block ID #$5.

Does this need to be fixed for the train?

@dom_walden The block message for Special:EmailUser is pretty broken... Before this task, if one of the blocks is sitewide the message looks like this:

(Note "the block ID is #." The previous failure was more subtle, though arguably less helpful since it didn't give any IDs...)

The problem is that the Special:EmailUser bypasses the formatter and chooses an inappropriate block message key ('blockedtext' for any block other than a partial block, which assumes that the block has a single numerical ID).

I would say that since this was already broken it shouldn't need to be fixed for the train - what do you think @Niharika?

Comparing block messages on (before the train) and

With the exception of T227174#5575175, I did not see any differences.

I tested these types/sources of blocks:

  • IP
  • Range (anonymous, sitewide and partial)
  • User
  • Autoblock (while logged in as the targetted user and logged out on the same IP)
  • Partial
  • Composite (combining a) 2 partial blocks and b) 2 sitewide blocks)
  • System (on my local machine)
  • Hidden (on my local machine)

and the message that was shown on these actions/pages:

  • Desktop editing
  • Mobile editing
  • Special:CreateAccount
  • Special:EmailUser
  • Special:PasswordReset
  • Special:Upload

I believe covering most if not all of the scenarios in Thalia's block messages document.

In case language matters (which I don't think it does) I also tested some of the block messages with user's interface language set to de. It looked OK to me (although I only speak very basic German).

I only tested the API briefly.

dbarratt closed this task as Resolved.Oct 15 2019, 9:17 PM