In T266731#6586870, @Dzahn wrote:

@Varnent Created this per our meeting and when I checked during it and you confirmed you could not see the ticket I also did not see you in https://phabricator.wikimedia.org/project/members/61/ but now after making this ticket... I do. But I changed nothing. Ehm... please try again to open that ticket.

Wasn't this meant to be done yesterday at T266598: Add Varnent to Wikimedia-NDA group?

In T251023#6585936, @Pchelolo wrote:

Now we have some logging in beta and production around the code @DannyS712 proposes to drop. let's wait and see if it's ever executed.

In T264948#6586134, @Umherirrender wrote:

Should the same apply to object[]?

In T251023#6585416, @Pchelolo wrote:

The proposed change is VERY scary. No explanation was really provided for why is this code not needed anymore, and I do not believe this code is no-op.

As a start in investigation, I propose to create a bogus change where the logging in that area is replaced with throwing an exception - let's see if any tests in CI fail.

I couldn't find the logs in production, so this makes me think the change is going to the right direction.

Also granted importer for a year, per IRC - see https://meta.wikimedia.beta.wmflabs.org/w/index.php?title=Special%3ALog&logid=54565

Granted sysop and interface admin for a year, see https://meta.wikimedia.beta.wmflabs.org/w/index.php?title=Special%3ALog&logid=54562

@CptViraj can you confirm that CptViraj is also your name on the beta cluster?

In T256367#6527209, @Urbanecm wrote:

I guess the last signoff needs to be from @gsingers as the CTO?

Will do, given that this will add yet another PHPUnit sniff should probably go after

This is intentional, since the namespace is protected
See rMW8862991ce1b1: Improve UI for page protection with $wgNamespaceProtection by @Anomie

@Urbanecm simplewiki 23 was a false positive - the use of rmspecials was in a comment. Should that be accounted for and excluded by the script?

Alternatively can be implemented via title blacklist

Forgot about this entirely, sorry

For now, the constraint system is completely internal, and until the backend is fully factored out of EditPage it should probably stay that way. I agree that the "perfect solution" is to eliminate these hooks if possible. The full migration to a backend cannot proceed until eventually the hooks passing instances of EditPage objects are removed, since the backend won't know about EditPage

In T258108#6579100, @ArielGlenn wrote:

It might be nice to prune some of the existing bot entry rows too. There's precedent for this sort of action, see T184485

This is a task for the core change, the sniff to add the functionality to codesniffer was done separately

In T127241#6578877, @Umherirrender wrote:

This task was created before the new phpcs tags was there, so would be nice to have it for @phpcs / phpcs as well.

It should, generally, be okay for core to extend core classes, but I agree that extensions should not be extending this, since it is not stable to extend

Having downloaded the video, steps to reproduce:
Visit, eg, https://de.wikipedia.org/wiki/Wikipedia
Progressively zoom in until the five article tabs (page, talk, view, edit, history) (locally: "Artikel Diskussion Lesen Quelltext anzeigen Versionsgeschichte") no longer fit on one line (for me this was 200% zoom in chrome)
Expected result: display is stable
Actual result:
Display alternatives between shifting the right set of tabs (Lesen Quelltext anzeigen Versionsgeschichte) to a separate line and hiding the right-most tab (Versionsgeschichte) entirely

In T247813#6515931, @DannyS712 wrote:

Given that this new sniff does nothing unless manually applied with @require-sorted-array, unless there are any objections soon I plan to +2 the patch

Fields using the same bit logic (as far as I can tell):
rev_deleted
ar_deleted
oi_deleted
fa_deleted
rc_deleted
log_deleted

In T263344#6575309, @matmarex wrote:

The patch for T252555 is deployed now, and this should be fixed as well. @DannyS712 Can you confirm that the issue no longer occurs?

In T251588#6131324, @eprodromou wrote:

OK, we need to review this in tech planning.

@Mooeypoo would you mind taking a look at the patch provided? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/631470

This will probably also need a maintenance script, and it might be worth tagging DBA to get feedback on the change before proceeding

In T265769#6570498, @Tgr wrote:

Nit: there is no point in repeating the class name name in the verbs, IMO. It's a bot password store, of course it's going to insert bot passwords. Just call it insert / update / invalidateAllForUser etc.

Plan:
BotPasswordStore service:
Handle DB
BotPassword::save -> BotPasswordStore::insertBotPassword and ::updateBotPassword
BotPassword::delete -> BotPasswordStore::deleteBotPassword

If WatchAction::doWatchOrUnwatch moves, so should WatchAction::doWatch and WatchAction::doUnwatch
The following services should be injected to the new service:
WatchedItemStore - currently retrieved from MediaWikiServices
PermissionManager - currently retrieved from MediaWikiServices
HookContainer - currently used via Hooks::runner()

Just came to report this, but it seems to have been done already
Can existing entries be fixed via script?

In T263592#6566337, @gerritbot wrote:

Change 635374 merged by jenkins-bot:
[mediawiki/core@master] Re-enable deprecation warning in Language::commafy() for non-numeric string

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

@eprodromou is it okay to move forward with this using ObjectFactory specs for DI?

Tagging user notice for change going forward
Should a maintenance script be added for removing the tag from old null revisions?

Just got this again on to.wikipedia - https://to.wikipedia.org/w/api.php?action=query&meta=notifications confirms 2 notifications that both appear to be for my first edit

Might I suggest instead

Patch merging now, should be ready to announce

^ patch rescoped to not include this, will do as a follow-up

@Ezarate to clarify, this is about viewing https://ticket.wikimedia.org/otrs/index.pl in Spanish, rather than viewing https://otrs-wiki.wikimedia.org/wiki/Main_Page in Spanish, right?

Caused by

'wgWMAPIPSidebarSpecialPages' => [
	// no default, fallback on extension default if extension is
	// installed, unnecessary otherwise
	'apiportalwiki' => [
		'AppManagement',
		'Notifications',
		'Preferences'
	],
],

since Special:AppManagement doesn't exist yet

In T202989#6557749, @Amorymeltzer wrote:

In T202989#6557660, @Thryduulf wrote:

There is no justification for preventing administrators viewing or restoring this.

Well, for restoring there is. Undeletion (in particular selective restoration after deletion) is tantamount to editing, which would otherwise be prohibited; depending on the page, that could also mean execution of code by users.