Background

Scenario: User:Apples is currently blocked.

If an admin navigates to Special:Block/Apples, the form will show the current block and the admin can determine if/how they want to update the block.

However, if they navigate to Special:Block and type in Apples in the username field, the page does not update, but a message saying Apples is already blocked displays when the admin submits the block. There is also a checkbox for the admin to verify the new block.

Problem to solve

If an admin is overwriting a partial block with another block, the parameters of the block could potentially be overwritten, requiring an admin to manually set the

Potential solutions

Idea 1 — Ajax load the rest of the block form once the admin selects a username.

• Requires UI work
• Needs a no-JS solution
• Makes the Special:Block/null workflow identical to the Special:Block/Apples workflow
• Does not require any error messages, except for no-JS.

Idea 2 — More specific error message

• Make the "Apples is already blocked" message more specific, potentially including:
  • Notifying if the expiration is longer or shorter
  • Notifying if the block is changing from sitewide to partial or vice-versa
  • Notifying if the contents of a partial blocked contains more or fewer pages/namespaces.
• For example:

Apples is already blocked. View the block log for more details, differences include:
* Your new block has a shorter expiration than the current block.
* Your new partial block has fewer pages than the current block.

Idea 3 — Different error message only in limited circumstances

• Show the current message for most block modifications.
• Only show a block message if the user is changing between sitewide and partial blocks.