move-rootuserpages is already needed to move root user pages (i.e. User:Example) and moving subpages (i.e. User:Example/Foo) makes sense for, eg, accepting user-space drafts and should not require a separate right

Okay, so I did some debugging:
Steps to reproduce: sort by oldest first in the feed, view the oldest, and try to advance

@Krinkle for example, on enwiki, an RfC (https://en.wikipedia.org/w/index.php?oldid=857728137#Sysop_as_requirement) held that 'crats shouldn't give themselves interface administrator rights. Setting wgGroupsAddToOthers['bureaucrat']['interface-admin'] = true; rather than using wgAddGroups would allow enforcing this. It would also ensure, per the use case in the summary, that there is always at least one 'crat left if they could only remove it from other users.

@MusikAnimal PR at PR at https://github.com/x-tools/xtools/pull/309

Awaiting merge of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/532961/

In T34959#4184307, @Daimona wrote:

This is actually doable, we only need to set a LogRestriction on abusefilter log (the one in Special:Log for creations/edits). The question is: who should be able to see it? To me abusefilter-view-private sounds like an exaggeration, while abusefilter-view may be reasonable.

I suggest treating the email address similar to other sensitive data (like IPs) and require abusefilter-privatedetails to view it

Awaiting functionality for multilingual sites to be targeted

In T232885#5492958, @Daimona wrote:

It's not only those. The full list is: blockautopromote, block, rangeblock, and degroup. IMHO, forcing 'disallow' to be enabled is not a good UX, so much so that we'll remove it when processing the actions (if other blocking actions are enabled). Given that https://www.mediawiki.org/wiki/Extension:AbuseFilter/Actions already hints that those actions implicitly disallow the edit, I think that we can just silently replace any of those with 'disallow', if the action cannot be performed. Maybe we could also add an OOUI info fields to the actions fieldset pointing to that page on mw.o.

Moving to inbox to get more eyes - can someone take a look at the patch? Automatically patrolling when tagging was activated based on T41208#468859, and the NPP community would like to have the ability to again choose not to patrol pages when tagging them. See https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers#Decoupling_maintenance_tagging_and_reviewing for current discussion

Tagging Core Platform Team as a feature request for review

Swapping can already be done by suppressing redirects

Unfortunately, looking at your edit filter log (https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%96%D1%83%D1%80%D0%BD%D0%B0%D0%BB_%D0%B7%D0%BB%D0%BE%D1%83%D0%BF%D0%BE%D1%82%D1%80%D0%B5%D0%B1%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9?wpSearchUser=Nigos&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchGroup=0&wpSearchFilter=) shows that all of the filter hits were to private filters. @Daimona can you take a look? If I recall you're a global edit filter helper

@Nigos can you provide some more information? What is the specific filter, and what edits should have been caught but weren't?

Has been resolved; https://en.wikipedia.org/w/api.php?format=json&action=query&generator=search&gsrsearch=Samuel%20Paley%20Park%20New%20York&gsrnamespace=6&gsrlimit=50&prop=imageinfo&iiprop=url%7Cdimensions%7Csize%7Ccanonicaltitle%7Ctimestamp%7Cextmetadata&iiurlheight=200&iiextmetadatafilter=License%7CLicenseShortName%7CLicenseUrl%7CArtist%7CImageDescription%7CGPSLatitude%7CGPSLongitude returns query results properly

Setting to declined on the assumption that the request is no longer applicable

A new namespace would definitely not be the best idea

If anyone wants to work on this, the code in Article::delete specifies that

$permissionErrors = $title->getUserPermissionsErrors( 'delete', $user );
if ( count( $permissionErrors ) ) {
	throw new PermissionsError( 'delete', $permissionErrors );
}

which, in call, results in a call to Title::getUserPermissionsErrors, defined as follows

public function getUserPermissionsErrors(
	$action, $user, $rigor = PermissionManager::RIGOR_SECURE, $ignoreErrors = []
) {
	// TODO: this is for b/c, eventually will be removed
	if ( $rigor === true ) {
		$rigor = PermissionManager::RIGOR_SECURE; // b/c
	} elseif ( $rigor === false ) {
		$rigor = PermissionManager::RIGOR_QUICK; // b/c
	}
	return MediaWikiServices::getInstance()->getPermissionManager()
		->getPermissionErrors( $action, $user, $this, $rigor, $ignoreErrors );
}

finally, PermissionManager::getPermissionErrors calls PermissionManager::getPermissionErrorsInternal

public function getPermissionErrors(
	$action,
	User $user,
	LinkTarget $page,
	$rigor = self::RIGOR_SECURE,
	$ignoreErrors = []
) {
	$errors = $this->getPermissionErrorsInternal( $action, $user, $page, $rigor );
	// Remove the errors being ignored.
	foreach ( $errors as $index => $error ) {
		$errKey = is_array( $error ) ? $error[0] : $error;
		if ( in_array( $errKey, $ignoreErrors ) ) {
			unset( $errors[$index] );
		}
		if ( $errKey instanceof MessageSpecifier && in_array( $errKey->getKey(), $ignoreErrors ) ) {
			unset( $errors[$index] );
		}
	}
	return $errors;
}

PermissionManager::getPermissionErrorsInternal takes the parameters:

private function getPermissionErrorsInternal(
	$action,
	User $user,
	LinkTarget $page,
	$rigor = self::RIGOR_SECURE,
	$short = false
)

if $short is true, once the first error is found is checks end, rather than finding all errors. However, getPermissionErrors has no mechanism to pass a value for short to getPermissionErrorsInternal, and so the internal function will always retrieve all applicable errors when called (indirectly) by Article::delete

There is no longer an editor user groups on testwiki, per https://test.wikipedia.org/wiki/Special:ListGroupRights

Can be credited using the edit summary, not a good idea to allow users to set someone else as the performer of their edit

No clear use case, no response from requester

Page deletion and blocking are very different features

Unneeded as a feature

If this is still desired, it can be hidden using CSS or javascript
The form can be selected using body.mw-special-Allpages div.mw-htmlform-ooui-wrapper to hide it via common.css

Not a bug; a page can have a different sort key than its talk page

In T25256#287101, @Bawolff wrote:

What do you mean "from category pages".
If you put HIDDENCAT on a category, it won't appear in the categorylinks section of a category page. But it will still appear in the subcategory list if its a subcategory. Do you mean to hide from the list of subcategories, or do you mean something else?

Given the addition of a hook that would allow circumventing current restrictions on unblocking self, tagging Core Platform Team for feature review

Reflect actual priority for developers - I support this, but its been sitting here for so long its clearly not "high priority"

Proposed solution:

What about, in the hidden comment added by MassMessageJob::makeText, adding the log id of the mass message submission? Each log entry there should be associated with 1 edit per page, and that would allow identical content to be resent later without causing deduplication issues, since a new message would have a new log entry. Just an idea, from the description on m:Talk:MessMessage

Great minds...

After T232884: Don't allow restoring autopromotion by blocked users is merged, I intend to resolve this by checking AbuseFilter::canEdit to determine if the interface should be shown, since that will cover both those without rights and those with rights but who are blocked from using them

@Daimona would you be willing to add me to T152394 and/or T187731?

They can be seen, as noted above, and can only be modified centrally due to the different rights needed. Boldly declining

In T191740#5491206, @CCicalese_WMF wrote:

In T191740#4682331, @Daimona wrote:

Works with web installer. The DB part is dependent on several tasks, so it won't probably be completed too soon.

@Daimona, what is the status of the DB work? Will this be ready for 1.34? The release branch is being cut on September 30.

PR filed at https://github.com/x-tools/xtools/pull/307

Closing as resolved based on rereading the above posts; if this isn't done yet please let me know

Tagging contributors-team for review per https://www.mediawiki.org/wiki/Developers/Maintainers

Tagging core platform team for review per https://www.mediawiki.org/wiki/Developers/Maintainers