In T345819#10355234, @Tgr wrote:

You could define a client hint data structure that can be attached to any API request (see e.g. centralauthtoken), have an API hook that writes it into some service it can be read from by the CheckUser logic, then add a hook mechanism to logoutViaPost that lets subscribers add information to the API request.

That last part seems a little annoying but seems useful enough that it's worth building some sort of core mechanism for it. E.g.

// in the mw.Api module
mw.Api.prepareExtensibleApiRequest = function ( hookName ) {
    let data = { params = {}, promise: $.Deferred().promise() };
    mw.hook( 'hookName' ).fire( data );
    return data.promise.then( data.params );
};

// in ready.js
api.prepareExtensibleApiRequest( 'extendLogout' ).then( ( params ) => {
    api.postWithToken( 'csrf', $.extend( {}, params, { action: 'logout' } ).then...
} );

// in CheckUser
mw.hook( 'extendLogout' ).add ( ( data ) => {
    data.promise = data.promise.then( () => {
        return navigator.userAgentData.getHighEntropyValues(...).then( ( values ) => {
            data.params.checkUser = { clientHints: values };
        } );
    } );
} );

This can't really be QA'ed until the feature is enabled on ptwiki.

Let's consider a Selenium test for this workflow as well to prevent regressions like this in the future.

I think this one can skip QA; we'll have to verify this once the extension is on ptwiki.

Re-assigning to Madalina per our meeting, to update the links and requirements.

I am declining this in favor of T380868: Use the Zendesk API for creating tickets for emergency workflow

There are several possibilities for this:

• a dispute resolution page,

There hasn’t been anything centralised for this for many years.

• a page for reporting urgent incidents to the administrators

https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Pedidos/Notifica%C3%A7%C3%A3o_de_incidentes

• a page for general questions from the community

https://pt.wikipedia.org/wiki/Ajuda:Tire_suas_d%C3%BAvidas or https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Esplanada/geral

In T50217#10356469, @kostajh wrote:

AIUI, the only thing left to do for this task is to attempt to run MediaWiki core's integration tests in parallel, the PHPUnit default suite (with database) task in mediawiki-quibble-vendor-mysql-php74.

I think we can resolve this. Nice work @ArthurTaylor!

@hashar and Release-Engineering-Team, @ArthurTaylor and I could use some guidance on how to move forward with this (please see discussions in attached patches).

AIUI the mechansim for this is https://wikitech.wikimedia.org/wiki/Url-downloader. Noting that it says, however:

In T380917#10359546, @A_smart_kitten wrote:

@kostajh, FYI, the files you've linked to are currently showing as restricted.

edit: not any more :)

In T380917#10359516, @Hey_man_im_josh wrote:

I certainly have felt like the bot's absence has had a negative effect on Wiki. One example is, during my NPP work, I patrol redirects. Every day this last week or two I'm finding at least 5-10 unreviewed redirects as the result of caste / clan related articles being redirected by IPs which have often ended up blocked as proxies by the time I find the redirect. I bet I'm missing quite a few as well with other editora marking those redirects as reviewed, whereas I'm reverting the BLARs which typically have very misleading edit summaries. Definitely some edits in contentious areas taking place that might not have otherwise.

Do we need a new special page, or would it be possible to add the functionality into the existing Special:GlobalBlock page?

I assume the amount of LTA-related proxy vandalism and abuse has increased

In T380868#10357736, @kostajh wrote:

We could also make the request to Zendesk from the client side, rather than route it through MediaWiki. That would avoid the rate limiting by IP issue, and need to deal with proxying.

Moving up to this sprint, if we have capacity.

We could also make the request to Zendesk from the client side, rather than route it through MediaWiki. That would avoid the rate limiting by IP issue, and need to deal with proxying.

This is specific to the desktop implementation, right? I don't see the same issue on Minerva.

This was done deliberately in rEREI404454b38e8c: form: Show dialog to visit Special:ChangeEmail but I also agree that there is no need to use the large size overrides here:

Current format:

In T240697#10355311, @MNeisler wrote:

@kostajh
No if Javascript was enabled at the time of the edit, this should still be counted as a JS edit event even if an ad blocker extension was installed at the time.

We identified this issue in an earlier analysis and added instrumentation in T263505 to help distinguish between people who have JS disabled and people who are using ad blocker extensions for all wikitext edits.

AIUI, the only thing left to do for this task is to attempt to run MediaWiki core's integration tests in parallel, the PHPUnit default suite (with database) task in mediawiki-quibble-vendor-mysql-php74.

This task might be a duplicate of T226869: Run browser tests in parallel

In T380711#10355514, @XXBlackburnXx wrote:

Just a note, in case this wasn't already known: Filtering on 'VPN' will also include non-anonymizing VPNs (e.g., school or workplace VPNs), which isn't covered by our NOP policy.
So, I would really encourage to introduce the tunnels[].anonymous variable in abusefilter (as ip_reputation_tunnel_anonymous?) alongside this one to filter specifically for anonymizing VPNs.

In T374718#10354951, @Xaosflux wrote:

Personally, if I'm considering placing a global block it would be useful to be able to query this information in one place (such as from metawiki) instead of having to go to local projects to do it, or going to external sources such as spur.us to do it. There isn't private info involved here, but putting a guardrail of administrator could be OK (as administrator is the level that would be reacting and placing blocks).

In T345819#10355053, @Tgr wrote:

This feels super hacky. Why not just use the JS API?

@Madalina could you update the acceptance criteria -- or remove it, as there are subtasks specifying in more detail?

Re-opening so that this can go through QA.

This patch does the following:

@Xaosflux we (Trust and Safety Product Team) had a brief discussion with Legal last week about this.

Once we've switched from the migration build of Vue 3 to the regular build of Vue 3, the compatConfig settings in component definitions will be ignored, and we should remove them.

In T240697#7127421, @MNeisler wrote:

Below is a snapshot of edits made by users without JS enabled across all Wiki Projects based on the new instrumentation added in T263505.
Data is also browseable by project and platform is available in this Superset Dashboard.

Percent of edits completed without JS by user type
Logged-In Users:
Desktop: 6.1%
Mobile: 3.15%

Anon Users:
Desktop: 0.98%
Mobile: 1.57%

All Users:
Desktop: 5.28%
Mobile 2.49%