Manual:$wgRestrictedGroups

利用者権限、アクセス制御、モニタリング: $wgRestrictedGroups
Conditions required for assignment of user to specific groups
導入されたバージョン:	1.46.0 (Gerrit change 1200077; git #bd2f4bd0)
除去されたバージョン:	使用中
許容される値:	(配列)
既定値:	[]
その他の設定: アルファベット順 | 機能順

詳細

This array contains criteria that must be met when user is added to a specific group. 構文は以下の通りです:

$wgRestrictedGroups[$groupName] = [
    'memberConditions' => $condsArrayForMember,
    'updaterConditions' => $condsArrayForPerformer,
    'canBeIgnored' => $canBeIgnored,
    'demote' => $demote,
    'scope' => $scope,
];

Where:

• $groupName – the name of the group, for which you wish to specify the restrictions, e.g. 'sysop'.
• $condsArrayForMember – the requirements that the user must meet in order to be added to the specified group. The syntax for specifying conditions is the same as for $wgAutopromote .
• $condsArrayForPerformer – the requirements that the performing user must meet in order to add the other user to the specified group. The syntax for specifying conditions is the same as for $wgAutopromote .
• If $canBeIgnored is true, then users with (ignore-restricted-groups) right are able to bypass the restrictions set for this group (both for the performer and for the target), if the conditions are not met.
• If $demote is true, members of this group who don't meet the criteria will be demoted when DemoteIneligibleUsers.php is run. Automatic demotion is only supported for groups with 'canBeIgnored' equal to false.
• $scope – list of scopes where the restriction applies. See below for explanation. If not set, the restriction applies to all possible scopes.

It's not needed to specify all items of the array. If 'memberConditions' or 'updaterConditions' are not present, they are assumed to be equal to [], which is interpreted as a condition that is always true. If 'canBeIgnored' is not specified, the requirements are assumed to be unignorable (i.e., (ignore-restricted-groups) has no effect on adding to this group). Groups without 'demote' specified are not demotable automatically.

If the conditions are not met, next to the group checkbox on Special:UserRights, the performer will see a message coming from MediaWiki:Userrights-restricted-group-<group-name> (which falls back to MediaWiki:Userrights-restricted-group-warning, if unspecified).

Continuous enforcement

All restricted groups have their conditions checked at the time of granting. The group can be given to a user only if the conditions are met or if the performer is allowed to bypass the condition check.

If the group has 'canBeIgnored' set to false, the conditions for group member will also be evaluated on every request. User, who no longer meets the conditions, will have the relavant groups disabled. Disabled groups do not give its member any rights, but the user is still reported as member of them in various places of the user interface.

Only groups that are enforceable continuously are supported for automatic demotion.

Scopes

In order to make restricted groups configuration usable for extensions which define their own set of group-like constructs (such as CentralAuth ), a concept of scopes has been introduced. A single scope is meant to apply to a single extension or a single kind of a group-like feature that's implemented by an extension.

If there happen to exist two group-like features coming from different extensions (or core and extension), specifying a scope in $wgRestrictedGroups can target the configuration at the selected scopes only. This behavior is used on Wikimedia to differentiate between local and global groups, which can have the same internal name, but don't have the same restriction configuration.

MediaWiki core defines a single scope for user groups ('local'). All groups supported by core belong to this scope, regardless of where they are defined (be it core's defaults, custom groups in settings or custom groups in extensions).

The only other known scope is defined by CentralAuth ('centralauth').

例

Basic conditions

The following replicates the conditions used on the Wikimedia cluster for the Temporary account IP viewers group – normally, the account must be older than 6 months and have 300 edits, but stewards can overrule these requirements:

$wgRestrictedGroups['temporary-account-viewer'] = [
    'memberConditions' => [
        '&',
        [ APCOND_EDITCOUNT, 300 ],
        [ APCOND_AGE, 86400 * 30 * 6 ],
    ],
    'canBeIgnored' => true,
];

Requiring 2FA for a user group

If you want to enforce requiring needing 2FA for a user group, like Extension:OATHAuth used to do with $wgOATHRequiredForGroups, the code change you would make would be to change:

$wgOATHRequiredForGroups[] = 'sysop';

becomes:

$wgRestrictedGroups['sysop'] = [
    'memberConditions' => [ 'oath.has_2fa' ],
];

Restrict only a local group

If you want a condition to apply only to a local スチュワード group, you can use configuration like the following:

$wgRestrictedGroups['steward'] = [
    'memberConditions' => [ /* ... */ ],
    'scope' => [ 'local' ],
];

With this configuration, any other type of group called 'steward' will be unaffected by the specified conditions.

関連項目

• $wgAutopromote
• $wgUserRequirementsPrivateConditions