Page MenuHomePhabricator

Bring block + issue user talk template workflow into Core
Open, Needs TriagePublic

Description

As Community-Tech team is rolling out Multiblocks, we're discovering a lot of gadgets and user scripts that assist sysops with issuing a user talk message after blocking a user. This is a very common workflow, so much so that I wonder if it should be part of Core. That seems better than reinventing the wheel over and over again.

Of course, not all wikis or individual sysops will follow this practice, so this should be configurable, perhaps via MediaWiki-extensions-CommunityConfiguration.

I envision a configuration where sysops can:

  • State whether or not they want this functionality at all
  • Provide a list of block templates that are commonly used
  • Be able to customize parameters passed to the templates and the values passed to them
    • Use TemplateData to grab available params
    • Maybe a dropdown of values we offer, such as the expiry and the reason (the username can be provided, too, but that can also be substituted with {{subst:REVISIONUSER}}).
    • Also an option for free-form wikitext entry, if the template takes a supplemental message
  • Whether to use substitution (in my opinion that should be enforced)

Then at Special:Block:

  • A new checkbox, "Issue block notice to the User talk page", could go under the "Additional options" at the bottom
    • Note, should not be present for IP ranges, though the same is true currently for other options like "Watch the target's user page and talk page")
  • Checking that will reveal a dropdown of the templates to select from, as configured by the community
    • And also a text field, if the template is configured to take a supplemental message
  • If the block reason matches one of the templates (templated reasons like {{anonblock}}), auto-select that from the dropdown
  • After a successful block is made, the talk page notice is sent and success/failure is shown to the user, beneath the current success message for the block itself. (They should be separate messages, I think)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I've said it on Discord, but the whole block progression (including appeals) is something that is ripe for a Flow-esque aspiration (search "appeal" from me from January 2025 and also from October 2024).

Issue block notice to the User talk page

This would be a potentially widely used core MediaWiki feature to act on user talk page (MassMessage, WikiLove and AutoModerator also posts on user talk pages, but they are extensions), so we may want to first resolve T123522: Implement a server-side mw.MessagePoster equivalent which will introduce a reusable and expandable core feature.

In some Fandom wikis, a user talk page is a non-wikitext Message Wall. If we only consider user talk page as Wikitext without a way for extensions to expand it, users in Fandom will see a feature that seems working but is actually broken. This is to some extent also the case of Wikimedia wikis: until very recently, in several wikis some or even all user talk pages are using Flow. There are currently not-yet-migrated pages using LiquidThreads. If Flow or LQT were still well-maintained and widely used, talk page notice would be broken without special treatment.

I like this idea. I think it would be really great if we could also coordinate this work with T352148: Blocks: add a structured category/reason field for cross-wiki use (currently unscheduled). TT352148 proposes to have a consistent structure for block reasons across wikis, which I think would fit well with also having a standard set of responses that could go with the structured reasons.