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
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.