I did a test, the edit just went though - were you able to verify it actually works if the automatic hcaptcha failed?

Thanks for updates and that there is a quick resolution. Should this be delayed we can insert some help text in to the error message - instructing end users to resubmit the publish as a workaround.

Inherit priority from merged in ticket; this is preventing a core end user function: Contributing content to the projects

Triggered by external reader report in ticket 2025120710005271

Possible dupe of T411927

Raised to high, this is preventing a core user function (page editing)

OK good point, so more tech work to do. Right now the access allows targeting anyone. It would need to be split, with 2 different permissions (r.g. remove, remove-high-security-user)

The underlying solution is technically solved, and these operations are now able to be done on-wiki, with logged - by those with access. However the only "functionaries" authorized are WMF support.

Note, we do want a delay on this to ensure there isn't a regression found in the 100% rollout

In T410845#11399994, @Tchanders wrote:

We could also reduce the margin between each checkbox:

Old	New

Special:PasswordReset shouldn't require reauthentication, as it is available unauthenticated

Also, despite the message, the login session is not expired, as navigating away from that page will resume the entirely non-expired login session

I've seen this happening again this week

Sheminghui.WU is done

IPBE, as in to override hard network blocks, tor, etc? No thank you.

My screenshot in the description shows it (185 vs 134) . Also, it was intermittently jumping all around, including down to zero; perhaps related to other processes crashing from T408632?

I'm seeing at least off-by-one errors on multiple queues, stewards queue right now is off by 2

Possible in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1188507

OK, yes "&hideanons=1" does seem to be working - so this is indeed a bug with the options doing the opposite of what they should be doing

Perhaps the junk queue should not be allowed to send agent notifications?

Prior test cleared in 90mins

Got 1 outbound email that was tested, it had a 30 hour delay.; will start a new timer

Other index have also been wrong, including showing ZERO tickets when there are actually tickets, making the folder not appear in the normal view - leading agents to not know there is help requests open

@jhathaway - how is the diagnosis going, the symptoms still persist.

Has the inability to send email out from VRT been confirmed to be related to the parent task, or is this a different problem?

Following up on progress at #wikimedia-sre ; expected resource is not yet on shift. Let's give them some time before next escalation.

Possibly causing T408967

Tested outbound email from 2025110210202022 - remote SMTP is a gmail destination, message not received.

I'm seeing multiple VRT issues going on:

Shouldn't that new user story be merged to this old more general story?

Able to duplicate on enwiki, metawiki.
Not able to duplicate on dewiki

Good news on that part. If not captured else where, perhaps when logging in with a recovery code a user notification could be fired (x recovery codes remaining) or something like that?

In T407167#11296802, @Catrope wrote:

In T407167#11296757, @Xaosflux wrote:

This is a significant problem. As loss of authenticator requires at a minimum TWO codes, that may only be used once to reset an account. (One to log on, one to disable).

That is no longer true. It used to be that you had to reauthenticate when disabling 2FA, but that has changed. Now, you can take any 2FA management action (adding or removing 2FA methods) within one hour of logging in. If you visit Special:AccountSecurity more than one hour after logging in, you will need to reauthenticate.

Of course the user could get logged out, or fail to fix their 2FA setup within an hour, or ignore the messages we're adding T406281, and those may be reasons to increase the number of recovery codes. But it is now possible to redo your 2FA setup with only one recovery code, you no longer need a minimum of two.

Note, the most popular end user documentation does not reflect that there is now only ever one code, and how to deal with the situation when your only code is burned.

We really need to be generating more than one code still. There are way to many ways to log on once and then get logged off.

Here is the user story I'm seeing:

This is a significant problem. As loss of authenticator requires at a minimum TWO codes, that may only be used once to reset an account. (One to log on, one to disable).

Getting this moved toward resolution, what is left besides:

Just a note this is not a project-specific issue for enwiki (e.g. https://wikitech.wikimedia.org/w/index.php?title=Special:DownloadAsPdf&page=Reporting_a_connectivity_issue&action=show-download-screen )

Multiple VRT tickets opened from customers on this today

Will this be useful on loginwiki? Esp. due to the difference in the way that project is used.

note, remove hack at enwiki https://en.wikipedia.org/wiki/MediaWiki:Specialmute-error-invalid-user when done

OK, looks like the resolution is that this is now logged in to the revision history of MediaWiki:GrowthMentors.json (despite that linked task above not be closed out yet)

@Pppery - how was this resolved?

Should we close the task about this problem, I don't think so. It is a core problem in our WebAuthn implementation. Perhaps T232336 will solve it, perhaps that will be abanadoned (that possible solution has been waiting for over 5 years without being delivered).

Here it is:

@Gehel see screen shot above, and below (before pressing space).

@Jdlrobson-WMF - perhaps I used the wrong phrase. Here is a screen shot of the search, with completion and with thumbnails - that only occurs once you hit "space":

Thank you, confirmed to have solved the reported user story as well:

@Ankry - perhaps you could advertise this at commonswiki

FYI: This topic was discussed at a stewards meeting today, follow up is to open a discussion about ways to improve the default warning text when users request vanishing.

Perhaps better clarification on what will be changed? (i.e. only metadata and User:USERNAME page titles). No "content" is ever changed by way of a rename/vanish.

Perhaps a more generic warning in the default verbiage, that once vanished you will not be able to submit any type of requests.

Seems to be a similar problem as was found in T373758

Multiple identical option blocks do not appear to be reducing in to one, they are just layering on top of each other.

"community-elected group of users" is a bit of a specific discriminator; noting that this is not the only group of volunteers that have this access; as it is included in the global group 'sysadmin' which includes volunteers

In short, action=clientlogin may return an EmailAuthAuthenticationRequest response - which I suspect AWB doesn't have support for today.

https://www.mediawiki.org/wiki/Help:Extension:EmailAuth is likely what you are hitting.

May not be needed, I'm not seeing a compelling user story to support the effort.

Tested in testwiki, yes this is still occuring

Is this still an issue?