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?

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?

In T364639#9786679, @Primefac wrote:

Note that the last time this worked was https://en.wikipedia.org/w/index.php?diff=1211086114 (29 Feb 2014), which was before T358810 was filed.

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).

This is a general condition about filters, not specific to only the 'bot' or 'minor' filter

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.

In T363548#9747981, @RoySmith wrote:

I'm not familiar with the codebase, so this may be a silly question...

The patch description describes a bug in persist() and how it is being replaced by updateKey() but the old code is still in place because of a dependency from WebAuthn. Does this mean that there still exists a different scenario that exposes this problem when the buggy code is invoked by WebAuthn?

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.

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.

In T363118#9734804, @Wargo wrote:

For me it works.

Are there hidden edits in contribs?

What do you see in Browser console (network)? Note dataContext=infobox and show details on this line.

retitled, reopened - OK so "display" part is maybe covered else where, but the follow part isn't covered there. If a redirect goes to:

Got a batch of users reporting a very similar error today: Unable to stash Parsoid HTML

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?

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

There seemed to be many related tasks, can someone point me to a specific sub task tracking this problem:

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 ~~~~~).

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:

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)

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)?

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.

Also, like last time, a null edit to the page is at least occasionally clearing the problem.

https://www.mediawiki.org/wiki/Extension:NoCat could be an option

Looks like these are all done now?

Any update on this? Being able to query the "emailable" status for an enduser is already publicly available (e.g. https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=users&formatversion=2&usprop=emailable&ususers=Xaosflux ) even a boolean value would be useful

T357118 suggests that anytime you have multiple blocks you get no useful information, and multiblock locals may make this worse?

That multiple block problem seems to be T233996 from 5+ years ago

@Tchanders and what happens when you click that "See details" button there in the MFE view?

Note: local workaround added in enwiki to https://en.wikipedia.org/wiki/MediaWiki:Minerva.css

In T357118#9528696, @kostajh wrote:

I think this task is suggesting that there should be parity with the message shown on desktop?

This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

Is this "fixed" as in "fixed but not deployed"? Because it is not fixed in production

T341626 has delivered the username, if it can deliver the timestamp this FR is really moot

In T341626#9426049, @Ladsgroup wrote:

In T341626#9425429, @Xaosflux wrote:

"server time" should suffice? (e.g. the results of a ~~~~~)

That could work, the biggest issue is that it will be unstructured and not really sortable which you would expect from a timestamp column but maybe meh? Maybe I go bother Sam (PM of moderators team) for a decision.

As the "username" part of this has been delivered now just the timestamp portion is outstanding

Unable to further troubleshoot customer's original problem that the PDF output for this specific article is malformed (inconsistent text font sizes / styling) - due to the Proton service not creating a new file