It may be included to engineer group as well, which doesn't include autoreview permission but allows to edit sysop-protected pages (editprotected).

In T313255#8390573, @MusikAnimal wrote:

The message needs to be translated. The '1 year' option is there if you force English for instance with ?uselang=en in the URL.

It would probably be better to leave the semantics of $wgRestrictionLevels as is, but allow a new setting, $wgActionRestrictionLevels, allowing to set overrides for actions defined in $wgRestrictionTypes. For configuration used on enwiki, it might be as follows:

Found a comment for T296154#7531622 regarding to this issue:

The current declaration of $wgRestrictionLevels for arwiki is:
'arwiki' => [ '', 'autoconfirmed', 'editautoreviewprotected', 'review', 'sysop' ]
For editor protection, the editeditorprotected right is used in some wikis. On arwiki, review is granted to editor, reviewer, and sysop groups. So it's needed to grant the editeditorprotected right to editor, reviewer, and sysop groups, and to change $wgRestrictionLevels array to the following:
'arwiki' => [ '', 'autoconfirmed', 'editautoreviewprotected', 'editeditorprotected', 'sysop' ]
See T321111 for details.

@Aklapper No, I just wanted to report a security bug. For nonexistent pages, there was such a bug which was already fixed (T259562). But, it's still actual for existent pages where edit protection level is lower than move protection level.

In T315345#8191719, @Legoktm wrote:

In T315345#8191714, @Amire80 wrote:

"Indefinite" is kind of correct literally, but not necessarily clear to non-native English speakers.

"Infinite" is clearer than indefinite, but sounds a bit too mathematical.

Even just in English when it comes to user blocks there is a lot of subtlety in this. Quoting from https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Indefinite_blocks: "Indefinite does not mean "infinite" or "permanent". An indefinitely blocked user may later be unblocked in appropriate circumstances."

The bug is still actual as of today. Here is https://translatewiki.net/w/i.php?title=MediaWiki:Managewiki-permissions-resetgroups-header/fr, it still shows the unrelated text:

Hi @Aklapper, this task is about general MW configuration, i.e. about MediaWiki in general.

Decreasing priority as no user is interested in making a resolution.

In T230601#5417732, @Daimona wrote:

In T230601#5417721, @Vlad5250 wrote:

I should repeat, the 'abusefilter-hide-log' and 'abusefilter-hidden-log' permissions are included into the (new) group 'suppress' group on WMF wikis. See ListGroupRights to see an entry named 'Suppressors' (this is about the new group).

Yes, thanks, I got it. I said it's because of a recent config change, and because core does weird things with the 'suppress' group.

I should repeat, the 'abusefilter-hide-log' and 'abusefilter-hidden-log' permissions are included into the (new) group 'suppress' group on WMF wikis. See ListGroupRights to see an entry named 'Suppressors' (this is about the new group).

Such action should be preformed for https://gerrit.wikimedia.org/r/529043 to use the editautopatrolprotected right for pages protected for autopatrollers.

An alternative solution is to modify /includes/Title.php and add this code, e.g., to use the autoreviewer protection level used with the editautoreviewprotected permission:

@Urbanecm : You have created this task and Assigned To yourself :)
And I support the changes that should be made.

I support removing requirement/dependence of "createpage", "createtalk" (and perhaps "move") rights on "edit" right, so in 1.34 a user should be able to create a page even they do not have permission to edit existing pages.

@Aklapper: I'm not a developer but I know how to resolve this task.

The ability to edit tags on individual revisions and log entries can be restricted to sysops with $wgGroupPermissions.

I see the name of the wiki is still shown as Викивести

I see that usergroup assignment is correct as now.