User Details
- User Since
- Nov 2 2014, 4:13 PM (512 w, 4 d)
- Availability
- Available
- IRC Nick
- xaosflux
- LDAP User
- Unknown
- MediaWiki User
- Xaosflux [ Global Accounts ]
Yesterday
Note: initial comments suggest not to use 'bot' assertation, feedback welcome on the link above.
Wed, Aug 28
@HMonroy can you provide additional information on this ask? Is this only about a specific UI element, not the underlying blocking capability?
Mon, Aug 26
Using the existing last modified and license sounds like an easy win (and helps to propagate the open license as well).
See also T157844
Sat, Aug 24
Fri, Aug 23
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).
Thu, Aug 22
Sun, Aug 18
any objections to at least initially flagging this account as bot on metawiki while this is being worked on?
Fri, Aug 16
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)
Thu, Aug 15
@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.
Tue, Aug 13
AM is already going to run based on on-wiki local .json files correct?
Sun, Aug 11
Thu, Aug 8
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.
Sun, Aug 4
Just for search notes, this was delivered as Special:GlobalVanishRequest
Wed, Jul 31
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:
Jul 29 2024
Jul 27 2024
It this already done, or something more specific in the UI than the title suggests? Admins can already place p-blocks on multiple namespaces:
Jul 26 2024
(Screen shot on merged in duplicate T371151 )
Jul 25 2024
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 )
Jul 23 2024
Not following where this will fail to appear?
@Niharika maybe these illustrations will explain better:
Jul 22 2024
sent by wikimail
Jul 19 2024
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:
Jul 18 2024
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.
Jul 17 2024
Jul 15 2024
Copying over from a VRT customer feedback:
A VRT customer reported this similar issue with a SVG image (File:Tianeptine2DACS.svg)
Jul 10 2024
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
Jul 5 2024
I think this is accurate to the current/near-term workflows. Notice the very inconsistent results in the user story of "remove my account":
Jul 4 2024
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.
Jul 3 2024
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.
Jul 1 2024
I'm seeing this problem:
Have global pref set to langauge:en
Jun 29 2024
Account locking already exists and could be used, while providing the means to undo a bad "vanish" still.
Jun 26 2024
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
Jun 20 2024
Jun 13 2024
Jun 12 2024
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)
Jun 3 2024
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.
May 23 2024
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.
May 19 2024
If this "disables" the phab account, will a new story of "CentralAuth unlocks should enable linked Phabricator account" be also addressed?