In T370370#10007844, @Amdrel wrote:

The patch I just uploaded inserts an entry using the existing 'setstatus' log action. This log entry will show up in the site-wide Special:Log page, but since the performer for vanishes is the renamer or the user configured by $wgCentralAuthAutomaticVanishPerformer for automatic vanishes, the log entry will not be viewable from the global account manager logs link since that filters by performer and not the affected user. Please let me know if this works or not and if I need to make changes.

In T367329#10005388, @Izno wrote:

Someone noticed on Discord that user talk pages (and I would guess subpages also were forgotten to be moved) are not being moved when this work flow vanishes someone. [...] Are there tickets for those?

It is still possible to request the old name manually via the rename page, not sure if the titleblacklist should disable direct creation of such name (old and new, but that could break CentralAuth in vanish the user, needs testing).

AccountVanishRequests should only be processing vanish requests (Special:GlobalVanishRequest), not other renames (Special:GlobalRenameRequest). How is it using two different naming patterns as noted in the task description?

Is this for JS or non-JS? The title says non-JS, but the first step is disable non-JS (use JS).

I confirmed on loginwiki.

The root cause of this type of issue should definitely be researched further, but I believe this particular task can be considered resolved.

I wonder if the puppet changes for T370436 did it. cc @Dzahn

Not sure when or how, but its no longer an issue.

Likely introduced in the recent Account-Vanishing work

Likely needs a Wikimedia-maintenance-script-run to fix the existing ones after the underlying cause is addressed

Security-Team: This can be made public.

@bd808 revoked them again.

You'd never have data for the target, so I don't know why the buttons are there for those.

A new set were compromised the same way.

In T370083#9992140, @Tchanders wrote:

Ahead of testwiki deployment, lets do:

• Stop adding the reveal IP buttons on Special:Log

In T369314#9983460, @KFrancis wrote:

Hello @JJMC89, please send you full name and postal address to [email protected] and I'll get the NDA processed. Thanks!

https://gitlab.wikimedia.org/repos/stewards/users/-/merge_requests/1 starts to address the differences in the dry run. See comments in P66165 and users.yaml.

In T303433#9945321, @kostajh wrote:

Are there circumstances where we want to set $wmgEmergencyCaptcha across all projects without involving SREs? If not, then the AbuseFilter + showcaptcha consequence seems like it would suffice for the use case described in this task.

• Should we only block account creation, so unblocked, logged-in temporary accounts can still edit?

They should prevent the same actions as local autoblocks.

• Should we allow global autoblocks for all global user block, or just temporary account blocks?

All global account blocks

• Should we only lookup IP addresses that were used for edits, or for all actions?

Match what is used for local autoblocks.

There's no need to drop support, just trop the tests. We don't have code that handles or tests the few changes from 3.7.0 to 3.7.1, so we don't need to run tests on it.

In T331738#9920203, @Ahecht wrote:

Anyone know why I got an email saying that I own a Cloud VPS project called "tools" that is going to be shut down? Did this go out to everyone with a Toolforge account?

This is impacting the wikis - bots are receiving maxlag errors.

There is no immediate impact to the wikis since the feature is disabled by default. As far as I can tell, this feature isn't documented yet.

In T345068#9908763, @Niharika wrote:

It sounds like there is agreement that we show the user the most recent IP we know of and let them know that that's what we are doing. I like the idea of using the info icon to do this.

now 503 Service Unavailable

Only the bot user group has the abusefilter-bypass-blocked-external-domains right by default. I've corrected the documentation.