@tstarling MergeUserTest::testMergeEditcount is now failing in a bunch of repos and blocking merges since it is loaded as a dependency. See, e.g., https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1029837

@Kizule I see you awarded a "thumbs down" token - can I ask why you oppose this?

Prior attribute-related change that can be used as a reference if helpful: https://gerrit.wikimedia.org/r/c/mediawiki/tools/codesniffer/+/786408

@Iniquity if you fill in the

Link to scc output for general sizing of codebases (https://github.com/boyter/scc):

part of the task description it might be easier for the security team to prioritize given just how *tiny* this extension really is (120 lines of PHP total and by my count 57 of those are comments and 14 are blank, so really 49 lines of PHP; no JavaScript)

In T353938#9702532, @DannyS712 wrote:

@Dreamy_Jazz any chance that this can be prioritized by T&S during your ongoing work of CU?

@Dreamy_Jazz any chance that this can be prioritized by T&S during your ongoing work of CU?

Just want to add a link to @Terasail's amazing script https://www.wikifunctions.org/wiki/User:Terasail/ReadableDiff.js which does some of this in the meantime client-side

In T241457#9693802, @Jdforrester-WMF wrote:

Extension has been archived per T352884.

In T361860#9691600, @Xover wrote:

In T361860#9691323, @DannyS712 wrote:

@Xover I created https://phabricator.wikimedia.org/P59624 that is restricted to WMF-NDA members and the subscribers of the paste (currently you), which should be secure to put the full headers

Thanks. But Phab still won't let me edit that paste. Only members of WMF-NDA and the author have the "Can Edit" capability...

@Xover I created https://phabricator.wikimedia.org/P59624 that is restricted to WMF-NDA members and the subscribers of the paste (currently you), which should be secure to put the full headers

Also affects ContentTranslation, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/1015683

Since I never learned the precedence rules, for me and anyone else reviewing patches that fix this: && is higher precedence than || per https://www.php.net/manual/en/language.operators.precedence.php

Just to connect: was previously archived at T248758 and then unarchived at T261923

<sorry, misclick>

Can you confirm that the user also cannot be blocked by specifying their user ID in the block API?

Doesn't this require the rights to move subpages though, i.e. generally only exploitable by advanced users?

Confirmed that the option shows up for me

https://phabricator.wikimedia.org/project/members/6986/ reports "Joinable By" as "All Users"
Moving to unbreak now since my understanding is that the project automatically allows access to the security tasks and now allows *anyone* to access security issues

<Adding to Project-Admins just for tracking>

Not sure when I'm going to have time for this, if someone else wants to work on it I don't want to block them

In T354577#9503830, @Htriedman wrote:

Hi @DannyS712! Have you made any progress on this?

@Jdforrester-WMF I created the patch linked above for LibUp to run upgrades (we missed this for 42.0.0) but we should first make sure that we manually get upgrades to one or two repos to make sure that things are working properly, it looks like there was a failure for the WikiLambda patch.

Because its not giving its own +2 the full tests for the gate-and-submit pipeline are running instead of the dedicated i18n tests, so this is taking up more CI processing and also leads to unrelated failures that then need to be manually merged (example https://gerrit.wikimedia.org/r/c/mediawiki/extensions/BlueSpiceUEModulePDFRecursive/+/992870)

Sorry if I didn't tag the right projects, wasn't sure where this should go

In T287234#9484807, @pmiazga wrote:

I tried to make a stab at this work some time ago (patches that Krinkle mentioned ) but then I abandoned the idea. Now I want to get this thing done and noticed you made a ticket for it and pushed a PR. Nice. Thanks.

@DannyS712 are you going to work on this? If not, let me take over this work.

Stalled for years with no movement/progress, no compelling reason articulated - boldly closing

In T354577#9451983, @MBH wrote:

I think there should be an option - hide previous versions or not. Currently ruwiki's bot hides all revisions, for example - all revisions of Putin's article since 2003.

Going to try and implement this. I'm assuming that this is all meant to be oversight-level suppression, rather than admin-level (unless we want both as options). Questions that will need an answer at some point

• Should editors be told that their names will be immediately hidden as editors?
• Should enabling/disabling this be in the public protection log (if editors are informed before saving then probably) (only a question if the suppression is oversight-level)
• Should each edit be logged individually as a revision deletion/suppression action? If not it might be confusing if the edits are later made visible. If yes, under what name - maintenance script?
• Should enabling this retroactively apply to all prior edits, or just new ones?

In T246674#8259078, @Aklapper wrote:

Removing task assignee due to inactivity as this open task has been assigned for more than two years. See the email sent to the task assignee on August 22nd, 2022.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

In T352182#9364058, @CDanis wrote:

Users are no longer impacted.

Unfortunately due to the nature of the outage (a DDoS) we can't publish more details.

If Traffic is not appropriate please let me know

Thanks - GlobalWatchlist is working properly too

testwiki also has GW deployed, and there (from 1.42.0-wmf.4) the api works to retrieve changes from both mediawiki.org and testwiki, but on meta when I add testwiki to the global watchlist (or presumably any other 1.42.0-wmf.4 wiki) it fails, so the issue is api requests from wmf.3 to wmf.4

Move out of hidden column

Move out of hidden column

Move out of hidden column

Just encountered this again and spent a while trying to figure out why there were no contributions to be found by a user -

Special:Drilldown comes from Cargo; adding Yaron who I don't think has security access