Where is the message being used?

In T248112#5984716, @Ammarpad wrote:

Where is the message being used?

I spotted it on PageInformation on a wiki that use protection restriction levels. Likely a few more places though.

Change 581677 had a related patch set uploaded (by RhinosF1; owner: RhinosF1):
[mediawiki/core@master] i18n: Add missing i18n for <restriction-protect>

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

It might be useful to backport to 1.31 and 1.33 too, depending on when it was starting to be used

In T248112#5984916, @Reedy wrote:

It might be useful to backport to 1.31 and 1.33 too, depending on when it was starting to be used

Sounds good to me, didn’t check when it started being used. Just 1.34+ as that’s where I spotted the bug.

Ok, so I see the problem. It's not a default one in MW core - https://github.com/wikimedia/mediawiki/blob/7a4df9b/includes/DefaultSettings.php#L5314-L5321

/**
 * Set of available actions that can be restricted via action=protect
 * You probably shouldn't change this.
 * Translated through restriction-* messages.
 * Title::getRestrictionTypes() will remove restrictions that are not
 * applicable to a specific title (create and upload)
 */
$wgRestrictionTypes = [ 'create', 'edit', 'move', 'upload' ];

So this isn't actually a core but, unless $wgRestrictionTypes should have protect by default? Protecting a page to limit protecting.. seems very meta and recursive

It's also not listed in the grep friendly comment https://github.com/wikimedia/mediawiki/blob/4147bd8/includes/specials/SpecialProtectedpages.php#L145

		// First pass to load the log names
		foreach ( Title::getFilteredRestrictionTypes( true ) as $type ) {
			// Messages: restriction-edit, restriction-move, restriction-create, restriction-upload
			$text = $this->msg( "restriction-$type" )->text();
			$m[$text] = $type;
		}

Is there an actual use case, or is this just someone adding it erroneously to whichever wiki (config) you were looking at?

In T248112#5984939, @Reedy wrote:

Ok, so I see the problem. It's not a default one in MW core - https://github.com/wikimedia/mediawiki/blob/7a4df9b/includes/DefaultSettings.php#L5314-L5321

Correct, it’s not default.

/**
 * Set of available actions that can be restricted via action=protect
 * You probably shouldn't change this.
 * Translated through restriction-* messages.
 * Title::getRestrictionTypes() will remove restrictions that are not
 * applicable to a specific title (create and upload)
 */
$wgRestrictionTypes = [ 'create', 'edit', 'move', 'upload' ];

So this isn't actually a core but, unless $wgRestrictionTypes should have protect by default? Protecting a page to limit protecting.. seems very meta and recursive

It's also not listed in the grep friendly comment https://github.com/wikimedia/mediawiki/blob/4147bd8/includes/specials/SpecialProtectedpages.php#L145

		// First pass to load the log names
		foreach ( Title::getFilteredRestrictionTypes( true ) as $type ) {
			// Messages: restriction-edit, restriction-move, restriction-create, restriction-upload
			$text = $this->msg( "restriction-$type" )->text();
			$m[$text] = $type;
		}

Is there an actual use case, or is this just someone adding it erroneously to whichever wiki (config) you were looking at?

The use case is people who have people other than admins allowed to protect things and and want to restrict which groups can protect a page.

In T248112#5984736, @RhinosF1 wrote:

In T248112#5984716, @Ammarpad wrote:

Where is the message being used?

I spotted it on PageInformation on a wiki that use protection restriction levels. Likely a few more places though.

Whatever extension allows this should define the messages, not core

In T248112#5984952, @DannyS712 wrote:

In T248112#5984736, @RhinosF1 wrote:

In T248112#5984716, @Ammarpad wrote:

Where is the message being used?

I spotted it on PageInformation on a wiki that use protection restriction levels. Likely a few more places though.

Whatever extension allows this should define the messages, not core

The option is part of the core config ‘$wgRestrictionTypes’ rather than an extension afaik.

See https://www.mediawiki.org/wiki/Manual:$wgRestrictionTypes

It is in core, yes

I have to wonder what other "actions" that might be useable/listed?

In T248112#5984957, @Reedy wrote:

It is in core, yes

I have to wonder what other "actions" that might be useable/listed?

Delete & protect are the non defaults

In T248112#5984958, @RhinosF1 wrote:

In T248112#5984957, @Reedy wrote:

It is in core, yes

I have to wonder what other "actions" that might be useable/listed?

Delete & protect are the non defaults

"It is possible to add additional actions which can't be restricted by default" - whatever adds these should define the messages. Enwiki adds a custom user group extendedconfirmed, but the messages for it aren't in core, because the messages are only needed as a result of extending the functionality. Unless core is going to officially support protecting against protection or deletion, it shouldn't define the messages

In T248112#5984959, @DannyS712 wrote:

In T248112#5984958, @RhinosF1 wrote:

In T248112#5984957, @Reedy wrote:

It is in core, yes

I have to wonder what other "actions" that might be useable/listed?

Delete & protect are the non defaults

"It is possible to add additional actions which can't be restricted by default" - whatever adds these should define the messages. Enwiki adds a custom user group extendedconfirmed, but the messages for it aren't in core, because the messages are only needed as a result of extending the functionality. Unless core is going to officially support protecting against protection or deletion, it shouldn't define the messages

Delete & Protect are both core components though, extended-confirmed is not.

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

In T248112#5984969, @Ammarpad wrote:

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

I’ve seen it used on wikis and definitely not a misconfiguration.

As pointed out on IRC, delete and protect are core actions and the config supports them so why not have i18n preset for them?

In T248112#5984971, @RhinosF1 wrote:

In T248112#5984969, @Ammarpad wrote:

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

I’ve seen it used on wikis and definitely not a misconfiguration.

Yes, the wikis are misusing $wgRestrictionTypes by adding protect and getting insane recursive loop of protect a protect action against a protect right in page protection. It might be OK for the wikis where you saw it, but not for core

In T248112#5984980, @Ammarpad wrote:

In T248112#5984971, @RhinosF1 wrote:

In T248112#5984969, @Ammarpad wrote:

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

I’ve seen it used on wikis and definitely not a misconfiguration.

Yes, the wikis are misusing $wgRestrictionTypes by adding protect and getting insane recursive loop of protect a protect action against a protect right in page protection.

insane recursive loop?

Let’s make the use case clearer:

• Wiki enables protect restriction level
• Wiki has a ‘consul’ group above admin as it’s a TestWiki and admin is given out easily
• Certain policy pages are protected so protection can only be changed by consuls.

In T248112#5985007, @RhinosF1 wrote:

In T248112#5984980, @Ammarpad wrote:

In T248112#5984971, @RhinosF1 wrote:

In T248112#5984969, @Ammarpad wrote:

This does not belong to core. I have added comment on Gerrit. Probably the wiki where you saw this is misconfigured

I’ve seen it used on wikis and definitely not a misconfiguration.

Yes, the wikis are misusing $wgRestrictionTypes by adding protect and getting insane recursive loop of protect a protect action against a protect right in page protection.

insane recursive loop?

Let’s make the use case clearer:

• Wiki enables protect restriction level
• Wiki has a ‘consul’ group above admin as it’s a TestWiki and admin is given out easily
• Certain policy pages are protected so protection can only be changed by consuls.

Even within Wikimedia there's a usecase - in T217005: Fix wgRestrictionLevels for all Serbian projects to fully work it is proposed to add a bureaucrat protection level.

It is removed in https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/512488/ ("To protect or unprotect a page, only sysop permissions are required.
Because of that, protection levels requiring higher level of permissions
than something a sysop normally has doesn't make sense.") But the page can be also protected against protection, so that only bureaucrats can edit or unprotect it.

Another potential usecase is to protect some page so that they may only be edited by ArbCom members.

(btw) Several years ago Wikimedia does have a "superprotect" level, but it's flawed in this sense.

In T248112#5985007, @RhinosF1 wrote:

Let’s make the use case clearer:

• Wiki enables protect restriction level
• Wiki has a ‘consul’ group above admin as it’s a TestWiki and admin is given out easily
• Certain policy pages are protected so protection can only be changed by consuls.

That does not makes sense still. The reason for protection is to restrict modification of page content, but by your scenario admins can still edit the page, move it and even delete it completely, (the only thing they can't do is protect/unprotect); this actually renders your 'protect-protect' setting even more illogical and useless.

If you say, no, the protection is also beyond admin, then that means simply you don't want the sysops to edit the pages. And in that case the logical thing to do is to set $wgRestrictionLevels = ['consul'] and then protect policy pages with 'consul' right which you'll now give to only consul user group. (this will already encapsulates your "protection can only be changed by consul").

If you again say no, the admins should be able to edit, delete and move the page, it's only "protection can only be changed by consul" then it's clear you just want a nonsensical setting.

The consequence of allowing message like this, is that anyone can configure their wiki with
$wgRestrictionTypes = ['history', 'revert', 'unwatch' ]; and also say they want core to have <restriction-revert>, <restriction-unwatch> and <restriction-history> messages. Even Wikimedia don't force its idiosyncratic messages to core, it confines them to WikimediaMessages.

In T248112#5985976, @Bugreporter wrote:

Even within Wikimedia there's a usecase - in T217005: Fix wgRestrictionLevels for all Serbian projects to fully work it is proposed to add a bureaucrat protection level.

No, that's a different thing. $wgRestrictionLevels is not what this task is about

It is removed in https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/512488/ ("To protect or unprotect a page, only sysop permissions are required.

You've misunderstood that commit message. He was saying that since "protect or unprotect are already rights available to sysops", then protection level (read: wgRestrictionLevels) higher than sysop does not make sense because on Wikimedia that means a sysop can protect a page with "bureaucrat level" and then now the page can only be unprotected by bureaucrats (which is inherently due to 'edit' right not '(un)protect' right itself).

In that scenario if bureaucrat group does not have '(un)protect' and no one is in both groups (sysop-crat) that means the page cannot be unprotected by local users.

For that Serbian wiki setting to be comparable to this task, $wgRestrictionTypes =['protect'] is what would be set. I don't think that will ever be allowed to slip through in code review because even though it works, it does not makes sense.

Another potential usecase is to protect some page so that they may only be edited by ArbCom members.

That's also different thing from the issue at hand. That'd be done with $wgRestrictionLevels (not $wgRestrictionTypes)

As far as I can tell, using "protect" should not be supported, per the explanation above.
Delete, on the other hand, makes a lot more sense. Eg, on enwikiversity, curators have delete, are not full sysops (custodians). See https://en.wikiversity.org/wiki/Special:ListGroupRights Here, it would be conceivable to protect a page so that only custodians could delete it.
In short, I suggest updating the documentation on mediawiki.org to only list deletion as a potential added restriction level

In T248112#5986139, @DannyS712 wrote:

As far as I can tell, using "protect" should not be supported, per the explanation above.
In short, I suggest updating the documentation on mediawiki.org to only list deletion as a potential added restriction level

Indeed. The variable already has some simple comment: "You probably shouldn't change this." But I believe that's not strong enough.

Change 581677 abandoned by RhinosF1:
[mediawiki/core@master] i18n: Add missing i18n for <restriction-protect>

Reason:
See task. Recreate if wanted.

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