Not closing the task myself in case I’m wrong, but I believe that this may be able to be called Resolved? The functionality appears to have been merged, & the only pending patch is a proposed backport to the REL1_43 branch.

Pinging a couple of people I’ve noticed involved with the Wikimedia-production-error tag in case they have an opinion on this (feel free to unsubscribe obviously!): @Krinkle as you’ve edited the criteria in the tag’s description before, @Reedy as I’ve noticed you filling/triaging production error tasks.

(given that this is being fixed in CentralAuth)

Looks like the manual changes made to non-English languages in the patch above may have been overridden by the translatewiki l10n-bot. https://github.com/wikimedia/mediawiki/commit/4c8ddb06bb48b55886d3610c07db487fddbf023e

Closing as resolved, as admin/intadmin rights on beta-commons have been granted; please reopen though if there’s anything left to do here that I’ve missed!

Adding Wikimedia-production-error, as per that tag’s description it can also be used to track Beta Cluster errors

In T387508#10652723, @sbassett wrote:

In T387508#10652690, @mmartorana wrote:

• I suggest deleting Vuln-WeakHash and keeping only Vuln-CryptoFailures, as weak hashes fall under cryptographic failures.

Archived: https://phabricator.wikimedia.org/project/manage/7772/

In T387508#10652998, @mmartorana wrote:

In T387508#10652845, @sbassett wrote:

In T387508#10652753, @mmartorana wrote:

I'd merge them.

So a merge would be a "rename one, delete the other" operation, I believe, as I don't think there's another way to merge them. And then we might want to update one set of tagged tasks or the other, as there would be a confusing, archived vuln- project for some tasks.

I think updating all the old tasks is too time consuming.

Thank you for drafting the Tech/News entry @ppelberg :D
Moving to the 'Announce in next Tech/News' column, now that the patch has been remerged.

In T313581#10643237, @Samwalton9-WMF wrote:

In T313581#10620688, @Trizek-WMF wrote:

It is possible to have a filter being conditional to a role. The Growth team does it with mentorship: the mentor role provides access to specific filters (they highlight their mentees' edits). We can imagine a configuration setting to provide access to a specific role (editor, autopatrolled, rollbacker...).

Regarding the APIs, shouldn't we have the same conditions that on the RC page, for consistency?

I think this is something we overlooked earlier, but I agree we could limit this in the RecentChanges UI, too. Perhaps access could be restricted to users with the patrol or rollback user right as a starting point?

In T387923#10636895, @kostajh wrote:

In T387923#10636866, @A_smart_kitten wrote:

Is it okay to create a feature-request task to track showing bot edits in Special:GlobalContributions, if this is something that might be enabled at a later date?

Yes, a new task for this would be great, thanks in advance for filing it!

Swapping MediaWiki-Configuration to Wikimedia-Site-requests, as (IIUC) this task is about removing obsolete flags from Wikimedia site config, rather than removing config variables from MediaWiki itself.

Migrating codebase/regression tags from T386873; adding @Sdkb as you’re subscribed to that task but not this one.

In T387923#10636109, @kostajh wrote:

Thanks @Ladsgroup.

I would be inclined to not do this work for now (we have too much other stuff going on), and do something more straightforward of telling the user that bot users are not supported by the tool. cc @Tchanders

ty for fixing this, @Ladsgroup :)

Should T386873: [SPIKE] page issues banner non-function on mobile legacy parser be merged here? If not, it might be worth adding the subscribers of that task to this one, given that AFAICS that task was a bug report prior to being turned into a spike.

I mean, that’s fair — imo if we’re going to do it then we should be consistent about it, but I also see where you’re coming from. (If anyone with Wikimedia-GitHub access happens to come across this task, feel free to delete the repo :p)

@Aklapper my understanding is that the current practice is for the GitHub mirrors of archived Gerrit extension repositories to be deleted, rather than being left in an emptied state.

(Also Phabricator? Unless I'm misunderstanding something)

Noting that the ActiveAbstract extension is being archived, per T382069: Undeploy and archive ActiveAbstract. (I’d edit the task description myself, but I’m not sure if the ActiveAbstract row should just be removed from the table above, or if something else should be done with it :))

Noting that the ActiveAbstract extension is being archived, per T382069: Undeploy and archive ActiveAbstract. (I’d edit the task description myself, but I’m not sure if the ActiveAbstract row should just be removed from the table above, or if something else should be done with it :))

Feel free to add checkboxes to this task description if you wish, but please do not create a new task.

Didn't see this when typing the last reply (d'oh!) - I've copied the majority of the template checklist over to this task. Obviously feel free to edit/refine as needed :)

In T382069#10623331, @Jdforrester-WMF wrote:

Most of the complexity of that task is for human-facing extensions that third parties might have used (hence the Wikidata stuff) or have i18n (hence the TWN stuff), which are irrelevant.

To be fair, ActiveAbstract is present on translatewiki. All of the template task's checkboxes under "Configuration/tests/integrations/etc.", "Repositories" & "Phabricator " also seem to apply in this case AFAICS.
Anyways, I'm not gonna create a template archival task for ActiveAbstract if there's opposition, but I do feel that creating one (or at least, copying over the majority of the checkboxes to this task's description) would be beneficial in this case :)

In T382069#10621872, @Novem_Linguae wrote:

In T382069#10621024, @A_smart_kitten wrote:

For clarity, is the plan to archive the ActiveAbstract extension at the same time as/immediately after undeploying it from WMF production? If so, it might be good to create a separate task to track the extension’s archival, to ensure that all the cleanup steps that need to be done get completed.

I was thinking the same thing. The gerrit repo archiving steps, phabricaror tag archiving steps, mediawiki.org archiving steps, and wikidata archiving steps seem relevant to this.

In T382069#10619398, @gerritbot wrote:

[integration/config@master] Zuul: [mediawiki/extensions/ActiveAbstract] Mark as archived

https://gerrit.wikimedia.org/r/1126085

@Aklapper To be honest I’m not sure if this is a regression - Special:GlobalContributions was only introduced (relatively) recently, and (anecdotally speaking) I can’t remember the behaviour being different to this on mobile in the past. I just hadn’t got around to figuring out the specific bug/filing a task about it yet 😅

It may potentially be worth noting that this can also sometimes occur when the target user hasn’t actually edited that many wikis — my GlobalContributions takes a looong time to load, even though (according to my CentralAuth) I’ve only actually ever made edits on a 8 individual wikis.

I believe that this also causes an issue when attempting to utilize the colon-separator system message on a translatable page (in order to ensure localized formatting in a section of wikitext that won't be marked for translation ). The example wikitext/use case I've been dealing with that caused me to come across this issue just now is:

Potentially a duplicate of T387081: Cannot download wikidata latest-all.json* dump?

Adding User-notice, as I think this might be worth an entry in Tech/News: given the duration that mobile web hasn’t given editors a visual indication that they have new 'notices' for, it might be surprising for the red ‘you have unread notifications’ icon to suddenly also appear when an editor has a new 'notice'. There’s also a general community interest in the current status of notifications on mobile - e.g., Wikipedia:Mobile communications bugs on enwiki.

In T387659#10614918, @Dreamy_Jazz wrote:

That's my understanding too. I did quickly look through how to fix this task when I added the sprint tag. Thanks for detailing this.

It's been my experience that IP user pages are only ever created by a registered user to indicate abuse.

At a very quick scan of the code:

In T387042#10613067, @Geertivp wrote:

How does wp.fr show my username?
https://fr.wikipedia.org/wiki/Wikipédia:Accueil_principal

From watching the linked screen recording, my immediate guess as to what might be happening here is:

• Tapping the ‘log out’ link appears to result in the user being logged-out in the background (i.e., while they’re on the same page).
• After having logged the user out in the background, MediaWiki then appears to try to redirect the user to a ‘you have been logged out’ page.
• Because the user has made changes in the editor, another part of MediaWiki might then trigger the browser warning of ‘do you want to leave this page?’.
• Tapping ‘stay’ might prevent the user from being redirected to a ‘you have been logged out’ page. However, because (at this point) the user may have already been logged-out in the background, it might not prevent the logging-out itself from taking place.

From the screenshot, it looks like this might be an issue with the Wikipedia mobile app on Android; and (at a search) I can find what seem to be matching message strings in the Android app's codebase.
It looks like this task might have unintentionally been sorted into an incorrect project; apologies for that.

In T387923#10603518, @Dreamy_Jazz wrote:

The reason this is the case is that DBA specified we could not store information on bot users, due to the concern of lots of writes being performed to the table for several high edit bot accounts.

Came across this task while going through the revision history of Developers/Maintainers -- just noting that this task is currently under the "Update unowned extensions" column of Temporary accounts, but VipsScaler was added to Developers/Maintainers in October 2024 with the information that MediaWiki-Engineering/Content-Transform-Team stewards this extension.

Looks like this seems to be an issue also affecting other bot accounts - I've edited/reframed the task accordingly :)

(I'm adding the MediaWiki-Internationalization tag in order to ensure that this task has an active project tag attached to it, in case I'm wrong about the behaviour being caused by an on-wiki message override.)

I did some looking into this. Disclaimer: while I think I've found what's causing the current behaviour, I know practically no Lua, and this is probably my first time doing a deep-dive into an issue like this, so please let me know if you think I'm wrong or if you think I've messed anything up!

FWIW, the date selector fields on Special:GlobalContributions currently don't appear to work (T387752).

@Jdlrobson-WMF I apologize in advance if I'm missing something here, but I'm a little confused as to how this task could be a duplicate of T381658, as (to the best of my knowledge) enwiki isn't yet using Parsoid by default, and - at first glance - T381658 seems to be describing a different issue to this. Please tell me if I'm missing something, though.

Works for me again using WIkimediaDebug & using a VPN

I can also reproduce with a VPN turned on. Maybe a datacentre closer to me is currently caching the working version of the page.

Hmmm.... for some reason, I can't personally reproduce the issue when visiting the page normally. But I can reproduce with WikimediaDebug turned on.

In T387468#10588267, @Ladsgroup wrote:

Well, there is. This patch fixes a user-facing issue.

This is true; however, whether it was merged (e.g.) today, tomorrow or the day after tomorrow wouldn't have had an effect on when the fix was rolled out to WMF wikis. Anyway, I've said my piece here so I won't say any more (but thank you for correcting me on the translatewiki issue /gen)

@Ladsgroup, imo I don't think there was a rush to merge this patch. For one thing it meant that @stjn couldn't give feedback on the patch before the CR+2; and in addition I'm not certain on whether we're meant to be modifying the message translations directly (my understanding was that any changes to the translated messages had to go through translatewiki, but I admit I could be wrong there).