Note: initial comments suggest not to use 'bot' assertation, feedback welcome on the link above.

@HMonroy can you provide additional information on this ask? Is this only about a specific UI element, not the underlying blocking capability?

https://meta.wikimedia.org/wiki/Meta:Requests_for_bot_status/AccountVanishRequests opened

Using the existing last modified and license sounds like an easy win (and helps to propagate the open license as well).

See also T157844

2FA audits are being performed by WMF/stewards against required groups - so this may be solved. The results of such audits are not published publicly.

Note https://foundation.wikimedia.org/wiki/Policy:Access_to_nonpublic_personal_data_policy/Exceptions has been updated to remove a hurdle for 'crats to be able to do this; at this point would need a new task - the "MediaWiki:Verifyoathforuser-text" message should likely be initiated along with such a request, to put in a warning to users that the results of that query are non-public information - at the very least for WMF wikis (if worded generically enough could be reusable).

any objections to at least initially flagging this account as bot on metawiki while this is being worked on?

Not a bug, existing feature, updated documentation.

Thank you for the update, regression marker withdrawn. Updated the documentation at https://www.mediawiki.org/wiki/Help:Preferences#Editing

(removed teahouse item, as it is no longer running at reference project)

@Jdlrobson the Teahouse listing above appears to have been deprecated, OK to remove from here?

Note: added electron incase this system is needed to pass that value on to proton, if it wouldn't be please untag that project.

AM is already going to run based on on-wiki local .json files correct?

Lock actions are not secret, so this is certainly not an inappropriate information disclosure problem; no issues with it being turned off if it is useless noise though.

Just for search notes, this was delivered as Special:GlobalVanishRequest

In T371499#10033897, @JScherer-WMF wrote:

In T371499#10033398, @Xaosflux wrote:

From a RACI perspective - who is Responsible for acting upon the reports? Because they are a key stakeholder. Is WMF staff taking this responsibility? If this is something that per-project volunteers are expected to manage, they likely need to end up on-project.

That's right. It needs to be per-project volunteers because the issues are primarily created by hardcoded colours in volunteer-maintained templates which we don't maintain. On the projects that you work on, where would you want to see these reports, and what would you like them to include?

From a RACI perspective - who is Responsible for acting upon the reports? Because they are a key stakeholder. Is WMF staff taking this responsibility? If this is something that per-project volunteers are expected to manage, they likely need to end up on-project.

More questions:

In T370679#10021473, @Niharika wrote:

@Xaosflux Would you consider this change sufficient to close this task?

It this already done, or something more specific in the UI than the title suggests? Admins can already place p-blocks on multiple namespaces:

(Screen shot on merged in duplicate T371151 )

FYI: Customers are still complaining that they can't "report" any details of their problem ( from https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=13268092 )

Not following where this will fail to appear?

In T370679#10006226, @Niharika wrote:

In T367329#10005388, @Izno wrote:

the system moving users is not flagged as a system bot like e.g. the Maintenance script user.

@Niharika maybe these illustrations will explain better:

sent by wikimail

more reader complaints, see https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=13262327 for example

And more divergences from even those design elements:

See linked bug about UX complaints.

Users have already complained about this user experience via VRT - they saw the dialog and wanted to share their problem, then nothing happens. And that it just silently disappears on narrow width is another UX miss. The bug here seems to be a problem in the UX design.

Note, this specifically is related to when that appearance menu is not in the gutter as in this image:

In T370417#9994971, @Dreamy_Jazz wrote:

Hi @Xaosflux. It is not yet possible to create global auto blocks and will be added in T368949.

It seems that the output screen verbiage is wrong because the message is customised on-wiki and has not been updated.

I will update this message now.

Perhaps this isn't actually happening, and the output screen is just wrong. See below for the output screen verbiage after globally blocking an account:

Similar to T370417, this should be optional.

I think the vanish workflow should have a help link (see T370397 ) ; however I don't expect this team to update local wiki pages which may have many non-technical nuances. Boldly declining in favor of adding the help link and updating central documentation. Of course, local projects may update any page their community maintains.

With this live, it should prob go in tech news.

Copying over from a VRT customer feedback:

A VRT customer reported this similar issue with a SVG image (File:Tianeptine2DACS.svg)

The documentation is a bit light onwiki still, perhaps a bit more attention would be useful. For example, if global account blocks are or are not bypassable with the local GlobalBlockWhitelist

In T366439#9956928, @Pppery wrote:

Am I supposed to be able to access that file? I can't.

I think this is accurate to the current/near-term workflows. Notice the very inconsistent results in the user story of "remove my account":

There seems to be a primary problem with parts of this, it is not completely addressing the user story of "I want my account removed". It is only looking at the story through the lense of "I want my account removed, and am going to tell you about it via a mobile app". Mobile app is the least used interface, and is only getting more hits because we have decided to put a remove my account button in there and are building hacks around making that work -- not addressing the primary user story. This will lead to inconsistent results based on the method the user intakes their account removal request. If a user wants their account removed, and we want to empower that - it should not matter if they indicate that via webform or an application shortcut.

These are likely good things, I've added this topic to next weeks steward meeting (it's been an ongoing topic). We also likely need more phab tasks on this to ensure we delivery a consistent result for the user story of "I want to deactivate my account" regardless of the mode of intake.

Production documentation is needed, possible at: https://meta.wikimedia.org/wiki/Global_blocks

Note: "option to delete all user pages cross-wiki." has been contested by the community. Especially as anything that the user published was already released under an irrevocable license.

So the collision seems to be between parallel use cases/workflows:

Then what is the process for "undoing" an "account vanish"? There may be a collision in the terminology and expectations here that need clarification.

I'm seeing this problem:
Have global pref set to langauge:en

Account locking already exists and could be used, while providing the means to undo a bad "vanish" still.

Thanks, SRP filed at https://meta.wikimedia.org/w/index.php?title=Steward_requests%2FPermissions&diff=27018303&oldid=27016350 (this is my homewiki so will let any other steward handle it)

Yup that's the "bug", just checking if this is something that needs to actually be done.

This is likely the 'group only exists locally' thing; the workflow is:
Grant self local steward, remove locally, revoke local steward

@jrbs - I think this is just a procedural thing, do you want us to remove this group from those users?

sure, seems to be a zero actual impact. Also seems to be makework cleanup, but whatever; if one or both of these projects want to remove this from the primary group they can pick where it should end up at the same time in the future

@1AmNobody24 from enwiki thread: (https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Heads-up:_Diff_colour)

c.f. https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1228844848#Disable_edit_summary_warnings_on_redirect_AES

FYI: runs in the last hour are passing now

Problem still occurring today and all recent requests have failed (see https://quarry.wmcloud.org/query/runs/all)

To be very clear, testwiki still collects and makes available the private data to the poll's election admins, so who can use this is still sensitve.

Note: "community complaints" that may be relevant are here: https://en.wikipedia.org/wiki/Talk:Main_Page#header_broken_in_monobook

The user story here is really, "I want to be able to specify a skin when previewing changes so that I can make sure the changes are compatible with different skins before publishing the change", making this "persist" is a proposed technical solution, but any solution to that story should work.

If this "disables" the phab account, will a new story of "CentralAuth unlocks should enable linked Phabricator account" be also addressed?