Manuel:$wgRestrictedGroups
| Droits utilisateur, contrôle d'accès et supervision: $wgRestrictedGroups | |
|---|---|
| Conditions nécessaires pour assigner un utilisateur à des groupes spécifiques |
|
| Introduit dans la version : | 1.46.0 (Gerrit change 1200077; git #bd2f4bd0) |
| Retiré dans la version : | Encore utilisé |
| Valeurs autorisées : | (tableau) |
| Valeur par défaut : | [] |
| Autres paramètres : Alphabétique | Par fonction | |
Détails
Ce tableau contient les critères qui doivent être remplis lorsque l'utilisateur est ajouté à un groupe spécifique. La syntaxe est :
$wgRestrictedGroups[$groupName] = [
'memberConditions' => $condsArrayForMember,
'updaterConditions' => $condsArrayForPerformer,
'canBeIgnored' => $canBeIgnored,
'demote' => $demote,
'scope' => $scope,
];
Où :
$groupName– nom du groupe pour lequel vous souhaitez spécifier les restrictions, par exemple'sysop'.$condsArrayForMember– contraintes que l'utilisateur doit vérifier pour être ajouté au groupe spécifié. La syntaxe pour spécifier les conditions est la même que pour $wgAutopromote.$condsArrayForPerformer– contraintes que l'utilisateur qui réalise l'opération doit vérifier pour ajouter l'autre utilisateur au groupe spécifié. La syntaxe pour spécifier les conditions est la même que celle pour $wgAutopromote.- Si
$canBeIgnoredvauttrue, les utilisateurs ayant le droit(ignore-restricted-groups)peuvent contourner les restrictions imposées pour ce groupe (à la fois pour celui qui fait l'action et pour la cible), si les conditions ne sont pas remplies. - Si
$demotevauttrue, les membres de ce groupe qui ne répondent pas aux critères seront rétrogradés lorsque DemoteIneligibleUsers.php sera exécuté. Rétrograder automatiquement est uniquement pris en charge pour les groupes où'canBeIgnored'vautfalse. $scope– liste des champs où la restriction s'applique. Voir l'explication ci-dessous. Si non initialisé, la restriction s'applique à tous les champs d'application possibles.
Il n'est pas nécessaire de spécifier tous les éléments du tableau.
Si 'memberConditions' ou 'updaterConditions' ne sont pas présents, ils sont supposés être égaux à [], ce qui est interprété comme une condition qui est toujours true.
Si 'canBeIgnored' n'est pas spécifié, les contraintes supposent qu'elles sont impossible à ignorer (c'est à dire que (ignore-restricted-groups) n'a aucun effet sur l'ajout à ce groupe).
Les groupes où 'demote' n'est pas spécifié ne peuvent pas être rétrogradés.
Si les conditions ne sont pas satisfaites, à la suite du groupe de cases à cocher de Special:UserRights, l'opérateur verra un message venant de MediaWiki:Userrights-restricted-group-<group-name> (qui se replie vers MediaWiki:Userrights-restricted-group-warning, quand non spécifié).
Consolidation continue
Tous les groupes restreints ont leurs conditions vérifiées au moment de l'attribution. Le groupe ne peut être donné à un utilisateur que si les conditions sont remplies, ou si l'opérateur est autorisé à contourner la vérification de la condition.
Si 'canBeIgnored' vaut false pour le groupe, les conditions pour les membres du groupe seront également évaluées à chaque demande.
L'utilisateur qui ne remplit plus les conditions verra désactivés les groupes correspondants.
Les groupes désactivés ne donnent aucun droit à leurs membres, mais ces derniers continuent d'en faire partie (ce qu'on peut le voir à différents endroits de l'interface utilisateur).
Seuls les groupes modifiables en continu peuvent être rétrogradés automatiquement.
Champs d'application
Afin de rendre la configuration des groupes restreints utilisable par les extensions qui définissent leur propre ensemble de constructions de type groupe (comme CentralAuth), le concept de champ d'application (scope) a été introduit. Un seul champ d'application est destiné à s'appliquer à une seule extension ou à un seul type de fonctionnalité de type groupe qui est mise en œuvre par une extension.
S'il arrive qu'il existe deux fonctionnalités de groupe provenant de différentes extensions (ou du noyau et d'extension), spécifier un champ d'application en $wgRestrictedGroups peut cibler la configuration uniquement aux champs sélectionnés.
Ce comportement est utilisé sur Wikimedia pour différencier les groupes locaux et les groupes globaux, qui peuvent avoir le même nom interne, mais ne disposent pas de la même configuration de restriction.
Le noyau de MediaWiki ne définit qu'un seul champ d'application pour les groupes d'utilisateurs ('local').
Tous les groupes pris en charge par le noyau ont ce champ d'application, indépendamment de là où ils sont définis (qu'il s'agisse des groupes par défaut du noyau, des groupes personnalisés dans les paramètres ou dans les extensions).
Le seul autre champ d'application connu est défini par CentralAuth ('centralauth').
Exemples
Conditions de base
Les lignes qui suivent sont une réplique des conditions utilisées sur la grappe Wikimedia pour le groupe Temporary account IP viewers – normalement, le compte doit avoir plus de 6 mois et avoir fait 300 modifications, mais les stewards peuvent modifier ces contraintes :
$wgRestrictedGroups['temporary-account-viewer'] = [
'memberConditions' => [
'&',
[ APCOND_EDITCOUNT, 300 ],
[ APCOND_AGE, 86400 * 30 * 6 ],
],
'canBeIgnored' => true,
];
Demander le 2FA pour un groupe utilisateur
Si vous voulez appliquer les contraintes 2FA sur un groupe d'utilisateurs, comme Extension:OATHAuth l'avait fait avec $wgOATHRequiredForGroups, modifiez le code ainsi :
$wgOATHRequiredForGroups[] = 'sysop';
devient :
$wgRestrictedGroups['sysop'] = [
'memberConditions' => [ 'oath.has_2fa' ],
];
Restreindre uniquement un groupe local
Si vous voulez qu'une condition s'applique uniquement à un groupe local Stewards, vous pouvez utiliser la configuration suivante :
$wgRestrictedGroups['steward'] = [
'memberConditions' => [ /* ... */ ],
'scope' => [ 'local' ],
];
Avec cette configuration, tout autre type de groupe appelé 'steward' ne sera pas affecté par les conditions spécifiées.