Consumer is still approved: https://meta.wikimedia.org/wiki/Special:OAuthListConsumers/view/5709c54e5e241577730e27c13e1a56cf

Seems like this may make https://meta.wikimedia.org/wiki/Global_reminder_bot no longer needed

Zunny claims to have fixed upstream in v6.5.20

See also T230968

It should also explicitly say that you will be publishing a new page/revision if this workflow is being used to author a new page.

OK thanks, that can be a different UI bug then!

OK, forget my comment above -- however this has resulted in a NEW problem - using Special:ChangeContentModel to "create" pages needs work - nothing about it's UI suggests using it will CREATE a page.

The user communication on this seems a bit off, "...all autoconfirmed users can now use Special:ChangeContentModel page to create new pages with custom content models..." ; that Special Page isn't used to "create" pages at all.

I reported there, though that is on a different release (not our LTS train) - but it could be shared code

Can someone check the log.. think it is in /opt/znuny/var/log/otrs.log ?

Example query: https://ticket.wikimedia.org/otrs/index.pl?Filter=%27Unlocked%27;QueueID=%273%27;SortBy=Selection%5B0%5D;View=%27Preview%27;OrderBy=Selection%5B1%5D;Action=%27AgentTicketQueue%27;ChallengeToken=fhGdeFnQQny5OSLtkuAePv0kPGciCBk9;

Possibly related to T421671 ?

FATAL ERROR:

This just started happening today, I think there was a software release yesterday

Note we also semi-regularly get (and process) requests to "un-vanish" accounts just because a project wants the account to have the old name for their records (typically related to disruptive users) so the "system user" is also a bit of a problem there.

I'm not sure what changed, but there is certainly a change around this date, the code referenced above may not be the cause, I don't know what the cause is.

I think this break the rarely used manual account un-vanish process, not to mention simply being inaccurate.

Yes, I'd think the errors should be cleaned up, is a sub-ticket needed?

I'm not sure what the cause of the behavior change is, but this is recent, only seems to be presenting in the last month.

I'm going to close this as no longer able to reproduce, please re-open if you can reproduce the issue.

@Nux for your use case (wanting to copy current code) try ?action=raw

Perhaps that log summary should link to a documentation page?

It is useful, but remove the sysadmin part in the message, a warning that a user has a high edit contribution count is still a good warning - perhaps even lowering it to 50000.

TheDJ to the best of my knowledge, that is only triggered when the facilitator processes the dashboard requested accounts. My note was just calling out that there seems to be a different hard-coded processes that goes to enwiki there.

One thing to keep in mind, we did a special workaround with the English Wikipedia so that mass registrations that run in to rate limits otherwise don't hold up this process. (See processing here: https://en.wikipedia.org/wiki/Special:Log/OutreachDashboardBot ) .

Unless I'm woefully missing something, ipinfo-view-arbitrary-ip has no specific user privacy issues - it is allowing the use of this tool to query our external service provider - and doesn't include wikimedia-specific information in the output. We do appear to be limited with the provider as to the volume of requests that we may generate, necessitating not having this be massively available.

The 'elevate to edit' that is in place now seems like it is a solve without having to go through those extra steps?

@jhathaway - never got a bounce back, suspect this can be resolved now.

I have resent from VRT for ticket 2026030410007057 ; should likely give it a couple of hours to ensure it didn't get a bounce

@MusikAnimal you may be able to read that task with your staff account, any suggestions would be welcome

These are currently temporarily disabled globally due to an issue being worked on

This issue is being actively worked on by staff and volunteers, ETA not yet available. Please monitor https://www.wikimediastatus.net/ for updates

@jhathaway Here is the reject data:

see also: T418803

v=spf1 include:_cidrs.wikimedia.org ~all
SPF record resolution:

Still occurring, VRT ticket 2026030410007057

Seems like a good first start. For community notification:

Yes, we can bundle (autoconfirmed) with things like steward, global sysop, etc - but for our more general wide users this seem onerous. For those starting off in small wiki wide-response, telling them to go make an edit on 800+ projects first to get their autoconfirmed teed up doesn't sound like a positive workflow either.

Taking a look at myself ( https://meta.wikimedia.org/wiki/Special:CentralAuth/Xaosflux ) - were it not that I had a global group, I would all of a sudden become un-autoconfirmed on ~591 projects, I don't think that is improving things.

As this is a dynamic group, will this end up revoking thousands (millions?) of existing autoconfirmed statuses?

I expect this is going to cause some headaches with global users, who today use utilities like User:Krinkle/Tools/Global_SUL.js to bootstrap things.

In T14518#11654861, @1F616EMO wrote:

I wonder why we can't grant userrights to all stewards on all wikis via the global user group, if we can allow them to self-promote to local stewardship and essentially gain the same right. No hacks would be needed if we handle everything locally.

In your event, turn on account requesting.

This doesn't seem like you are using the dashboard to create accounts, and are trying to create them directly on the project. Have you tried using the dashboard account creation process?

Seems like the only part of a test you need is "can the dashboard create requested accounts" when the requester is on a blocked address? Once the SUL account gets created it's not a dashboard issue anymore. Regarding what SUL shows as the 'homewiki', yes that would require a change - but also SUL homewiki's are really that important.

OK, what is it that is preventing the account from existing locally? If it is a block that an admin would have dealt with they still can.

I know the dashboard-created accounts are already bypassing ratelimits and has enwiki ipblock exemption. Is it actually failing to create accounts still? I agree this isn't ideal; just trying to what the biggest blocking issues are. One I can see is if there is a global block, the local project may need to exempt the users locally so they can contribute, but that would happen even if they were created locally.

Not that this couldn't be useful, but what "doesn't work"? If a SUL account exists it can be granted exemptions on local projects.

(note to clean up https://meta.wikimedia.org/wiki/MediaWiki:Group-user.js )

I had tried the front end attach, it failed with "There already is a local account for the specified global account."

reported in VRT 2026012810005875

Regardless, they can just locally implement oversight filters

T290324 is rolling out now, is this still needed?

Perhaps a little 'NO SIGN" button, maybe right justify it to keep it away from the others?

ok, updated above

Is a current workaround to:

1. Remove email address, save
2. re-add email address, save

?

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