In T282624#7080539, @Xaosflux wrote:

@jrbs not sure why you left enwiki off your list, but we'd appreciate being in your announcements list.

In T267054#6693436, @tstarling wrote:

I think the User::isValidUserName() call can just be removed. The worst thing that can happen is that the DB will have to search for nonexistent rows. If that's a performance problem, the check can be moved to the caller of GenderCache. But some callers (e.g. ApiPageSet) are getting the inputs from an already validated source.

In T282624#7080463, @jrbs wrote:

In T282624#7080416, @Izno wrote:

... Reaching out and getting agreement would be a good idea. There are many wikis with restrictive policies under the understanding that local bureaucrats can indeed add I_Admin.

In T282624#7080456, @Rschen7754 wrote:

I assume there are legitimate reasons for this, along the lines of: 1) nothing is making bureaucrats check to make sure 2FA is enabled for interface admins before granting 2) bureaucrats also are not required to have 2FA at present.

This is all true. interface-admin is an extremely powerful right that can cause serious damage. This move is primarily to close any loopholes that have the potential for abuse. Stewards can now check 2FA status for accounts requesting access to this right, per T209749, which as you say, the 'crats cannot.

Okay, there is now documentation at https://www.mediawiki.org/wiki/Manual:Revision.php/Migration#Hooks for all of the hook replacements except for ParserFetchTemplate -> BeforeParserFetchTemplateRevisionRecord which I don't understand how to update

Forgot to close this earlier - now uses WVUI for everything possible, will continue to update as WVUI gets more features

In T278857#7073343, @Legoktm wrote:

What is npm installing on those repos? y18n doesn't show up as vulnerable on https://libraryupgrader2.wmcloud.org/vulns/npm for those repos...?

In T278857#7073329, @Legoktm wrote:

Seems to have been fine? Please reopen if something is actually wrong.

@Aklapper you marked this as having been fixed upstream with a patch merged there - is there a timeline for when that will be deployed to the WMF phabricator instance?

I'm happy to take a look at patches if you want. A basic migration guide to just fix the Revision uses is dumped below (and I'll probably write this better and post it somewhere easier once the class is fully removed). Doesn't cover all of the hooks, just those that translatewiki uses in extensions as far as I can tell (including those that appear used in semantic mediawiki).

Was about to file a ticket for this, but found this task. Added some notes

Selecting the user ids for users that have a given mentor, where the user is not a bot, the user is not indefinitely blocked, and the user either registered recently or has an edit. Formatting and order below is kind of ugly

$tables = [ 'growthexperiments_mentor_mentee' ];
$fields = [ 'gemm_mentee_id' ];
$conds = [];
$joins = [];

Can I suggest not just mass replacing with UserFactory if the uses are eventually going to be replaced with UserIdentityLookup or similar and migrated to UserIdentity/Authority?

@Vlad.shapik for future reference for these tasks and patches, they are for *replacing uses of the methods* in the different extensions, so the methods can be hard deprecated in core, and should be named accordingly - its confusing to see tasks and patches saying hard deprecate the methods in a bunch of extensions

From gerrit. reformatted a bit, but its a bit messy

I left a bunch of notes, but in general I don't think this is an improvement to the UI either with or without action blocks being enabled. I created 3 patchdemos for testing (the relevant fourth, no action blocks and without this patch, is just production) [1][2][3] and tried them out - based on my own experience with blocks as a sysop, the old interface was more intuitive. But, that might just be me - can I suggest soliciting feedback from other sysops?

The standard "read only" banned is misleading in this case - the window will not be preventing edits, just a couple of other actions (see task description) - is it too late to clarify this?

Something I noticed testing a different patch on patchdemo (without this redesign, but with action blocks enabled):

In T247143#7051429, @DannyS712 wrote:

Okay, we're getting close! Current status:
First couple patches, removing the hooks that use Revision objects and starting to remove deprecated support for Revision in other places, has already merged and will go out with the train.
Next batch is ready to go, but I'm waiting until after the train to split them up a bit. Once https://gerrit.wikimedia.org/r/c/mediawiki/core/+/683964 merges, the only remaining use of Revision in core will be in the Revision class itself, and in its tests. At that point

• update extensions that, like core, supported deprecated Revision object parameters: Wikibase (repo), EntitySchema, and Parsoid
• Wait for a new version of Parsoid to be tagged and deployed to vendor
• Wait at least a week since the rest of the changes to remove the uses of the Revision class in core

Then we can merge the actual removal (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/684071)

1. Risky Patch! 🚂🔥

We can use some of the logic in AssertCountSniff to skip past the first parameter - will try to work on this soon

Okay, we're getting close! Current status:
First couple patches, removing the hooks that use Revision objects and starting to remove deprecated support for Revision in other places, has already merged and will go out with the train.
Next batch is ready to go, but I'm waiting until after the train to split them up a bit. Once https://gerrit.wikimedia.org/r/c/mediawiki/core/+/683964 merges, the only remaining use of Revision in core will be in the Revision class itself, and in its tests. At that point

• update extensions that, like core, supported deprecated Revision object parameters: Wikibase (repo), EntitySchema, and Parsoid
• Wait for a new version of Parsoid to be tagged and deployed to vendor
• Wait at least a week since the rest of the changes to remove the uses of the Revision class in core

Then we can merge the actual removal (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/684071)

1. Risky Patch! 🚂🔥

In T247476#7049438, @Ladsgroup wrote:

Is that error related to jade and its content model? It doesn't look like it TBH

The original issue for the signpost was resolved after a few hours

In T247476#7047673, @Ladsgroup wrote:

I can't reproduce the error anymore given that jade is gone. Let's just call it done?

(this is a configuration change, not a change to the extension itself)

Not sure what the root cause is, but sent a hotfix to replace the php error with a nicer PermissionsError

+1 from me, active developer and trusted on production wikis

In T281072#7032256, @Reedy wrote:

Pick your dupe: T275432: MassMessage not delivering, T255135: MassMessage delivery not taken place

Might qualify for UBN, not sure

In T281050#7032155, @Reedy wrote:

So like I say, the failure needs handling better, for sure, maybe some documentation improvements surrounding it...

But using action=edit to handle content model changes might not happen, and I guess it's less likely Fandom would backport it to their version of 1.33

I've marked Rename Phabricator project as done, @Aklapper took care of that https://phabricator.wikimedia.org/project/manage/210/#77240

In T199377#4923820, @Ladsgroup wrote:

Given that the PageBlock extension is written by @Legoktm. Let's ping him to see what is the best course of action here.

There is a pending patch (https://gerrit.wikimedia.org/r/c/mediawiki/libs/ObjectFactory/+/676348) to move the code to a new namespace Wikimedia\\ObjectFactory\\ instead of just in Wikimedia\\, suggest including that within the next release (and that would probably warrant making it 3.1.0 instead of 3.0.1)

In T280890#7026700, @Xaosflux wrote:

@DannyS712 I think you may have done some related work? I actually though that this was possible in the past? I see that the very similar T22399 has also been ignored for 7 years, preventing any way to unpatrol a page at all - at least the unreview function exists, but seems to be excessively restricted.

In T273482#7024263, @Daimona wrote:

In T273482#7023999, @DannyS712 wrote:

Its impossible for phpcs to know (in the general case) if a method is inherited on not, its just for hooks where the naming is simple that its possible to tell

Then I would argue that phpcs is not the right tool for enforcing style of method names. Perhaps it might be always disabled if the current class is a subclass of anything?

In T273482#7023575, @Daimona wrote:

In T273482#7022502, @DannyS712 wrote:

@Daimona the patch I sent fixes this for the code that implements these hooks, do we also want to suppress the warning on the interfaces themselves? Or should we leave it to make sure that new hooks being introduced don't have underscores in them?

I recognize that I haven't been sufficiently clear in the task description, but this issue is not just for hooks. The real point is that it's an inherited method. As such, the sniff should:

• Not warn if the method is inherited from an ancestor class
• Warn if it isn't

Nothing more to remove before 1.36 is tagged, new work is at T262707: Remove core fallbacks to global $wgUser [1.37]

@Daimona the patch I sent fixes this for the code that implements these hooks, do we also want to suppress the warning on the interfaces themselves? Or should we leave it to make sure that new hooks being introduced don't have underscores in them?

renaming to "permission checker" would be changing the meaning and scope, and should not be bundled with fixing the actual name - instead of "otrs-member" it should be "vrt-member" or whatever the migration group decides

It might have been a duplicate, but that other task should probably be merged here since this is where everything is. Plus, there are open patches for this task

Should be easier to do once T157658: Factor out a backend from EditPage merges

In T278653#6952256, @DannyS712 wrote:

In T278653#6952253, @Jdforrester-WMF wrote:

Yeah, WFM. Not aware of any open tasks/patches that we should wait for; anyone have a differing opinion?

Might want to wait for https://gerrit.wikimedia.org/r/c/mediawiki/tools/codesniffer/+/673773 from T278010