User Details
- User Since
- Nov 2 2014, 4:13 PM (505 w, 1 d)
- Availability
- Available
- IRC Nick
- xaosflux
- LDAP User
- Unknown
- MediaWiki User
- Xaosflux [ Global Accounts ]
Fri, Jul 5
I think this is accurate to the current/near-term workflows. Notice the very inconsistent results in the user story of "remove my account":
Thu, Jul 4
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.
Wed, Jul 3
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.
Mon, Jul 1
I'm seeing this problem:
Have global pref set to langauge:en
Sat, Jun 29
Account locking already exists and could be used, while providing the means to undo a bad "vanish" still.
Wed, Jun 26
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
Thu, Jun 20
Thu, Jun 13
Wed, Jun 12
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?
May 17 2024
FWIW, I wasn't able to reproduce with a a local block (the message word wrapped inside the box just fine)
Was this on mobile?
May 16 2024
May 10 2024
Based on reports in https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1223218225#Anchor_issue_with_LT/GT_symbols_(redux) this appears to have broken between 2024-04-04 and 2024-04-10
Note from testing at https://test2.wikipedia.org/wiki/Talk:T364639
Reopening, but redefining - as T323948 is about "blocks", we can keep THIS ticket for the same concept for "globalblocks" - however, it should be expanded to the same use case, not ONLY "proxy" blocks.
I'm going to call this task itself WONTFIX, as the idea would be accomplished by T323948; which could be used for this or any other reasons as desired by administrators. "Proxy" blocks are already administratively considered in some cases if they should apply to everyone or just unregistered accounts, applying to "not confirmed" or not could still be an option that admins could choose, even if a block category were introduced, and "proxy" was the the type. Discussions about when certain blocks should be used can stay with communities and their representative administrators.
So there wouldn't need to be an additional "option to allow confirmed users to edit from IPs targeted by proxy blocks" - if the blocker wanted them to edit in a block they classified as an "open proxy" block they just wouldn't apply it to confirmed users (what T323948 would create)? And doing T323948 could achieve this even if T352148 never completes. Point being I don't think we would need to build another technical check.
There is no such thing as a "proxy block", so is this a request to create a new block flag? I can't see why it would need to be so specific to the underlying reason of the block either, as opposed to the ticket this was split from. (i.e. if you want to make a block for non-confirmed, building software to differentiate why one of those non-confirmed blocks is technically different from another one seems like overkill -- the block reason can already explain the block motive).
May 8 2024
This is a general condition about filters, not specific to only the 'bot' or 'minor' filter
Apr 29 2024
Apr 26 2024
Agree that progress has been made on improving support, but as you mentioned there is yet to be a workflow released to production support for non-staff, nor a commitment from staff that they are ready to support significantly expanding the "testers". fawiki could be a good early adopter once that is ready, and extendedconfirmed type groups seems like a good candidate.
It probably doesn't need to be private, as the avenue for triggering the availability problem requires you to already have the secret information for the account that would be impacted
Marking as declined due to the still insufficient recovery support for expanding the userbase on this for to users that haven't been very carefully warned.
Marking as declined due to the still insufficient recovery support for expanding the userbase on this for to users that haven't been very carefully warned.
Apr 23 2024
I don't have the client to test this use case right now, I was just providing information that there were no oversighted or revdel revisions that could have been changing this specific result.
Apr 22 2024
Apr 15 2024
retitled, reopened - OK so "display" part is maybe covered else where, but the follow part isn't covered there. If a redirect goes to:
Apr 14 2024
Got a batch of users reporting a very similar error today: Unable to stash Parsoid HTML
Apr 13 2024
Ah yes there is that anchor link.
There is no actual section on the page called "top" - and no one else would be able to follow it using that link. However, this all seems to be something that your gadget is handling, not part of mobile. Have you checked with the gadget maintainers?
Please clarify what you mean by "on mobile". Are you using the Wikipedia app, if so for what operating system? Are you using the Mobile Web?
Apr 12 2024
This is the redirect being used in the example above: https://test.wikipedia.org/w/index.php?title=Anchor_Link_Test&redirect=no
Example of it working on whatever the engine that vector is using is:
Please retitle as appr - I'm suspect this is actually a problem with one back end search software vs another, not with the skin - however the name of the search engine is not readily advertised to report this
Apr 1 2024
Mar 29 2024
Mar 28 2024
There seemed to be many related tasks, can someone point me to a specific sub task tracking this problem:
Mar 21 2024
No, for example being very slightly off the revision timestamp should be no big deal. Ideally they would match, or be very close. (If the timestamp has to be calculated and submitted, instead of using a magic keyword like ~~~~~).
Mar 17 2024
expect this will still be an issue even when ip-masking is enabled - due to the lack of an account state message either way
As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!
A similar issue was found and resolved in a different component here: T297719
Screen shot, showing lack of licensing information:
Mar 6 2024
Assuming this form is not going to check, may want to explicitly call out the situations where vanishing is going to be declined in the form - so we don't just get churn. (primarily - if you are blocked anywhere)
Feb 29 2024
A major use case for the local project is:
- There is some disruption from some network
- A range-block may stop the disruption
- Check for collateral damage (i.e. non-disruptive contributions from the network) first
- Decide if the range-block is the best option
That sounds like a local community concern, which can be addressed by policies and procedures.
There is no software security issuehere.
In most WMF projects "autopatrol" is only in sysop, bot. I can't see why we would want to prevent a community from assigning someone this group if they want to without also making them one of those other groups. Additionally, the assertion that "everyone has" autopatrol is false. For example, see ruwiki. Not only do they have non-admin/non-bot intadmins, but they also do not have anygroup with autopatrol. dewiki is deprecating patrol as well (see T316393).
On WMF wikis at least, each project with oversighters decides how they want to intake such requests to their workflow - it is certainly not consistent, by choice. Would this replace all of the other systems with some sort of of-wiki workflow (akin to perhaps the globalrenamequeue)?
Feb 27 2024
What is the chart attempting to show? e.g. on commonsiki it appears this will change from (bot, sysop) to (none)? Or is it currently manually at (bot,sysop) and it will change to (default) ((which will be bot,sysop))?
Will this tool restore the ability to get results currently available from Special:Contributions/IP/Mask -- frequently used by admins when considering and managing rangeblocks.
Feb 23 2024
Also, like last time, a null edit to the page is at least occasionally clearing the problem.