Update Special:Block to match the design
Open, NormalPublic8 Story Points

Description

Acceptance criteria
  • Special:Block matches the design (except functionality that has not yet been built). Changes include:
    • Add Actions to block section label
    • Add Editing checkbox
    • Add tooltips (copy below)
    • Align Pages and the input field to the same line
    • Move & relabel Account creation, Sending email and Editing their own talk page
    • Make the Expiration label bold
    • Make the Reason label bold
    • Align the reason dropdown + text field to one line
    • Add the Additional options section label
    • Make the checkboxes under 'additional options' two column (all other checkboxes not present in the design should be in this section.)
    • Every input field should extend to match the endpoint of the pages and namespace input fields, as per the design in Prateek's comment.
  • Verify Special:Block functions as expected on both RTL and LTR languages
  • Get a final OK from @Prtksxna before merging and closing.

Designs

  • Mobile:


    Tooltips copy
    • Sitewide: Sitewide blocks prevent the user or IP from editing every page on the wiki and all other contribution actions.
    • Partial: Partial blocks can be configured to block the user or IP from editing certain pages and/or performing other contribution actions, such as uploading files or sending email.
    • Pages: Select existing pages to prevent the user or IP from editing. The corresponding talk page and subpages are not automatically blocked.
    • Namespaces: Select namespaces to prevent the user or IP from editing within.
    TBolliger triaged this task as Normal priority.
    Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptAug 24 2018, 9:39 PM
    TBolliger updated the task description. (Show Details)Aug 28 2018, 6:25 PM
    TBolliger updated the task description. (Show Details)

    @TBolliger

    Is it ok if the editing checkbox is implied?

    What this means is that if you had a partial block, and you were to uncheck Editing and click Reblock the list of pages would be lost.

    If the list of pages needs to be retained, then we can make the checkbox explicit in which we would create a column in the database to save whether this is an editing block or not.

    What's the tradeoff here? On a purely technical level, is there a major difference in risk and effort?

    IIRC changing the database will require another conversation with the DBAs, which is added complexity. But not difficult.

    In general I'd prefer we do everything we can to preserve data, even if it isn't being actively applied. But this also sounds like a cornercase. We can also consider adding error messages as an alternative low-cost solution.

    @TBolliger

    The trade off is as you described.

    The proper way to do this would be to create a new column in the database and preserve the status of the checkbox. It provides a better user experience and is more straightforward from a code/API perspective.

    The only downside is having to do another schema change, which is time consuming (on other teams), but is not very much effort on our team. However, as Wikitech puts it:

    Schema changes on a live database are hard, and they should not be done lightly. That doesn't mean that schema changes should be avoided, not at all, a good database design is essential for security and performance.

    https://wikitech.wikimedia.org/wiki/Schema_changes

    I would recommend doing the schema change, but I wanted to notify you that there _is_ an alternative (albiet less than ideal) if you didn't want to go that route.

    aezell added a subscriber: aezell.Sep 24 2018, 10:29 PM

    I would prefer to avoid the time constraints that another schema change will cost us. IMO, we need to button up Partial Blocks.

    It sounds like @TBolliger is open to alternatives that would be much easier if less correct. Let's implement one of those alternatives and see how much push back we get, if any.

    I have a very strong hunch that non-editing blocks will be very infrequent — much less modifying a partial block to become a non-editing block.

    Let's go with the simplest solution. I'm sure we'll find some situations during QA that need error messages, potentially as part of T205147: Update the “USERNAME is already blocked” message if the user is partially blocked.

    TBolliger updated the task description. (Show Details)
    TBolliger added a subscriber: Prtksxna.

    I have one issue with the design that we may be able to fix directly in software. On the current tool, all the text input and dropdowns take the same width:

    But in the new design, the different elements have different widths — username and expiration, pages and namespace, and finally reason:


    In my opinion every input field should extend to match the endpoint of the pages and namespace input fields.

    TBolliger updated the task description. (Show Details)Nov 2 2018, 5:15 PM
    TBolliger updated the task description. (Show Details)Nov 7 2018, 10:48 PM

    In my opinion every input field should extend to match the endpoint of the pages and namespace input fields.

    Agreed 👍🏽

    TBolliger updated the task description. (Show Details)Tue, Nov 13, 4:15 PM
    TBolliger updated the task description. (Show Details)Thu, Nov 15, 6:02 PM