Manuel:Droits utilisateurs

This page is a translated version of the page Manual:User rights and the translation is 100% complete.
Outdated translations are marked like this.

Les droits utilisateur sont des permissions (comme la possibilité de modifier des pages ou de bloquer des utilisateurs) pouvant être attribuées à différents groupes utilisateur. MediaWiki est fourni avec un ensemble par défaut de droits utilisateur et de groupes d'utilisateurs, mais ils peuvent être personnalisés. Cette page décrit les droits et les groupes par défaut et comment les personnalisér.

Pour l'information concernant la manière d'ajouter ou de supprimer des utilisateurs wiki individuels dans les groupes, voir Help:Droits utilisateur et groupes et Manuel:Configurer les groupes d'utilisateurs dans MediaWiki .

Modifier les permissions de groupe

Par défaut MediaWiki donne certains accès à des groupes définis (voir plus bas). Vous pouvez changer les droits par défaut en modifiant le tableau $wgGroupPermissions dans LocalSettings.php avec la syntaxe.

$wgGroupPermissions['group']['right'] = true /* ou faux */;
Dans une installation par défaut, $wgGroupPermissions est initialisé dans includes/DefaultSettings.php, mais il n'est pas présent dans LocalSettings.php. Vous aurez besoin ensuite de l'ajouter dans ce fichier.

Si un membre est dans plusieurs groupes, il cumule les droits de chacun des groupes dont il fait partie. Tous les utilisateurs (y compris les utilisateurs anonymes) sont dans le groupe '*'; tous les utilisateurs enregistrés se trouvent dans le groupe 'user'. En plus des groupes par défaut, il vous est possible d'en créer arbitrairement de nouveaux en utilisant le même tableau.

Exemples

Cet exemple empêchera l'affichage de toutes les pages qui ne figurent pas dans $wgWhitelistRead , puis autorisera pour les utilisateurs enregistrés uniquement :

$wgGroupPermissions['*']['read'] = false;
# La ligne suivante n'est actuellement pas nécessaire car elle est définie par défaut. Mettre '*' à faux ne supprime pas les droits pour les groupes qui ont certaines valeurs individuelles à vrai !
$wgGroupPermissions['user']['read'] = true;

Cet exemple empêche de modifier toutes les pages, puis réautorise seulement les utillisateurs ayant des adresses courriel confirmées :

# Désactivez-le pour tout le monde.
$wgGroupPermissions['*']['edit'] = false;
# Désactiver également pour les utilisateurs : par défaut, 'user' est autorisé pour la modification, même si '*' ne l'est pas.
$wgGroupPermissions['user']['edit'] = false;
# Faire en sorte que les utilisateurs avec des adresses courriel confirmées soient dans le groupe.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Masquez le groupe de la liste des utilisateurs.
$wgImplicitGroups[] = 'emailconfirmed';
# Finalement, mettez-le à « true » pour le groupe désiré.
$wgGroupPermissions['emailconfirmed']['edit'] = true;

Créer un nouveau groupe et lui assigner des permissions

Vous pouvez créer de nouveaux groupes d'utilisateurs en définissant des autorisations pour le nom dédié au groupe dans $wgGroupPermissions[ 'group-name' ]<group-name> est le nom actuel du groupe.

En plus de l'assignation des droits, vous devez créer ces trois pages wiki et remplir leur contenu :

  • MediaWiki:Group-<group-name> (contenu: Nom du groupe)
  • MediaWiki:Group-<group-name>-member (contenu: Nom d'un membre du groupe)
  • MediaWiki:Grouppage-<group-name> (contenu: Nom de la page du groupe)

Par défaut, les bureaucrates peuvent ajouter ou retirer des utilisateurs de n'importe quel groupe. Néanmoins, si vous utilisez Manuel:$wgAddGroups et Manuel:$wgRemoveGroups , vous pouvez les adapter à la place.

Exemples

Cet exemple créera un groupe arbitraire projectmember qui pourront bloquer les utilisateurs et effacer des pages, et dont les modifications sont masquées par défaut dans les derniers journaux de modification :

$wgGroupPermissions['projectmember']['bot'] = true;
$wgGroupPermissions['projectmember']['block'] = true;
$wgGroupPermissions['projectmember']['delete'] = true;
le nom du groupe ne peut pas contenir d'espaces, donc utiliser 'random-group' ou 'random_group' au lieu de 'random group'. De plus il est recommandé de n'utiliser que des minuscules pour créer un groupe.

Dans cet exemple, vous voudriez probablement aussi créer ces pages :

  • MediaWiki:Group-projectmember (contenu: Project members)
  • MediaWiki:Group-projectmember-member (contenu: Project member)
  • MediaWiki:Grouppage-projectmember (contenu: Project:Project Members)

Ceci assurera que le groupe sera référencé en tant que Project members dans tout l'interface, et qu'un membre sera référencé comme un Project member, et les aperçus relieront le nom du groupe au Project:Project members.

Cet exemple désactive par défaut l'accès en écriture (modification et création de page), crée un groupe nommé "Write" et lui donne les droits d'accès en écriture. Les utilisateurs peuvent être ajoutés manuellement à ce groupe via Special:UserRights :

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['createpage'] = false;
$wgGroupPermissions['writer']['edit'] = true;
$wgGroupPermissions['writer']['createpage'] = true;

Dans cet exemple, vous voudriez probablement aussi créer ces pages :

  • MediaWiki:Group-writer (contenu: Writers)
  • MediaWiki:Group-writer-member (contenu: Writer)
  • MediaWiki:Grouppage-writer (contenu: Project:Write)

Supprimer les groupes prédéfinis

Médiawiki installé contient un nombre de groupes prédéfinis. La plupart de ces groupes peuvent être supprimés en supprimant les clés correspondantes dans les tables des droits, parmi lesquelles $wgGroupPermissions[ '<group-name>' ]. Pour les détails, voir ci-dessous.

Exemple

Cet exemple va supprimer complètement le groupe des Bureaucrates. Il est nécessaire de s'assurer que chacune de ces six variables n'a pas d'initialisation dans chacun des groupes que l'ont veut supprimer de la liste affichée par Special:ListGroupRights; néanmoins, le fait d'enlever l'initialisation dans $wgGroupPermissions suffira à supprimer le groupe de Special:UserRights. Ce code doit figurer après chaque ligne require_once qui ajoute des extensions comme $RenameUser contenant du code qui attribue au groupe des bureaucrates les permissions par défaut.

unset( $wgGroupPermissions['bureaucrat'] );
unset( $wgRevokePermissions['bureaucrat'] );
unset( $wgAddGroups['bureaucrat'] );
unset( $wgRemoveGroups['bureaucrat'] );
unset( $wgGroupsAddToSelf['bureaucrat'] );
unset( $wgGroupsRemoveFromSelf['bureaucrat'] );

Pour certaines extensions (Flow, Semantic MediaWiki, etc...), les permissions sont ajoutées pendant l'enregistrement de l'extension ou dans une fonction d'enregistrement. Dans ce cas, il sera nécessaire d'utiliser une fonction d'enregistrement dans LocalSettings.php pour supprimer certains groupes utilisateurs prédéfinis:

$wgExtensionFunctions[] = function() use ( &$wgGroupPermissions ) {
    unset( $wgGroupPermissions['oversight'] );
    unset( $wgGroupPermissions['flow-bot'] );
};


Note sur le groupe appelé "user"

Avec le mécanisme ci-dessus, vous pouvez supprimer les groupes sysop, bureaucrat et bot, qui - s'ils l'utilisent - peuvent être assignés via le système des droits utilisateur usuel. Néanmoins, il est actuellement impossible de supprimer le groupe user . Ce groupe n'est pas assigné via le système standard d'attribution des droits. Par contre, chaque connexion de l'utilisateur se fait en tant que membre de ce groupe. Ceci est codé en dur dans MediaWiki et ne peut pas être changé facilement actuellement.

Liste des permissions

Les droits utilisateur suivants sont disponibles dans la dernière version de MediaWiki. Si vous utilisez une version plus ancienne, vérifiez Special:Version sur votre wiki pour savoir si elle est couverte dans la colonne « versions ».

Droit Description Groupes utilisateurs qui ont ce droit par défaut Versions
Lire
read Lire les pages - quand mis à faux, il surcharge les pages spécifiques avec $wgWhitelistRead
  Avertissement : positionner les droits utilisateur "read" (permettant de voir toutes les pages) à false ne protègera que les pages wiki (article, discussion, ...) , mais les fichiers téléversés (images, fichiers, documents... dans les sous-répertoires $wgUploadPath ) resteront toujours consultables en utilisant l'accès direct par défaut.
Utilisez les informations des pages Manuel:Droits d'accès aux images et img_auth.php si vous avez besoin de ne restreindre l'affichage des images et l'accès au téléchargement de fichiers qu'aux utilisateurs connectés.
*, user 1.5+
Modifier
applychangetags Appliquer des balises avec ses propres modifications - nécessite les droits edit user 1.25+
autocreateaccount Connexion automatique avec un compte utilisateur externe - une version plus limitée de createaccount 1.27+
createaccount Créer des comptes utilisateur - register / registration *, sysop 1.5+
createpage Créer des pages (qui ne sont pas des pages de discussion) - nécessite les droits edit *, user 1.6+
createtalk Créer des pages de discussion - nécessite les droits edit *, user 1.6+
delete-redirect Supprimer des redirections composées d’une unique version (notez-bien que cela n'est pas nécessaire si le groupe possède déjà les droits delete) 1.36+
edit Modifier les pages *, user 1.5+
editsemiprotected Modifier les pages protégées avec « Allow only autoconfirmed users » - sans protection en cascade - requires the edit right autoconfirmed, bot, sysop 1.22+
editprotected Modifier les pages protégées avec « Allow only administrators » - sans protection en cascade - requires the edit right sysop 1.13+
minoredit Marquer les modifications comme mineures - nécessite les droits edit user 1.6+
move Renommer des pages - nécessite les droits edit user, sysop 1.5+
move-categorypages Renommer des pages de catégorie - nécessite les droits move user, sysop 1.25+
move-rootuserpages Renommer la page principale d’un utilisateur - nécessite les droits move user, sysop 1.14+
move-subpages Renommer des pages avec leurs sous-pages - nécessite les droits move user, sysop 1.13+
movefile Renommer des fichiers - nécessite les droits move et que $wgAllowImageMoving soit à vrai user, sysop 1.14+
reupload Écraser un fichier existant - nécessite les droits upload user, sysop 1.6+
reupload-own Écraser les fichiers existants que l’on a soi-même téléversés - nécessite les droits upload (notez que cela n'est pas nécessaire si le groupe a déjà les droits reupload ) 1.11+
reupload-shared Écraser localement des fichiers présents sur un dépôt partagé - (si l'un est positionné) avec les fichiers locaux (nécessite les droits upload) user, sysop 1.6+
sendemail Envoyer un courriel aux autres utilisateurs user 1.16+
upload Téléverser des fichiers - nécessite que les droits edit et $wgEnableUploads soient à vrai (true) user, sysop 1.5+
upload_by_url Téléverser des fichiers depuis une adresse URL - nécessite les droits upload (Avant 1.20, il a été donné aux sysops) 1.8+
Gestion
bigdelete Supprimer des pages ayant un gros historique (comme défini par $wgDeleteRevisionsLimit ) - nécessite les droits « delete » sysop 1.12+
block Bloquer ou débloquer les modifications par d’autres utilisateurs - Les options de blocage concernent l'interdiction de modifier et de déclarer de nouveaux comptes, ainsi que le blocage automatique d'autres utilisateurs de la même adresse IP sysop 1.5+
blockemail Bloquer ou débloquer l’envoi de courriels par un utilisateur - permet d'interdire l'utilisation de l'interface Special:Emailuser pendant le blocage - nécessite les droits block. sysop 1.11+
browsearchive Rechercher des pages supprimées - par Special:Undelete - nécessite les droits « deletedhistory » sysop 1.13+
changetags Ajouter et supprimer de façon arbitraire des balises sur des versions individuelles et des entrées de journal - actuellement inutilisé par les extensions user 1.25+
delete Supprimer des pages 1.5–1.11: autorise la suppression et la restauration des pages.
1.12+: permet de supprimer des pages. Pour le restauration, la permission 'undelete' existe maintenant, voir ci-dessous
sysop 1.5+
deletedhistory Voir les entrées effacées des historiques, mais sans leur texte associé sysop 1.6+
deletedtext Voir le texte supprimé et les différences entre les versions supprimées sysop
deletelogentry Supprimer et restaurer des entrées particulières du journal - autorise la suppression/restauration d’informations (texte de l’action, résumé, utilisateur qui a fait l’action) concernant des entrées spécifiques du journal (nécessite le droit deleterevision) suppress 1.20+
deleterevision Supprimer ou restaurer des versions particulières de pages - autorise la suppression/restitution des informations concernant des révisions spécifiques (texte de la révision, résumé des modifications, utilisateur ayant fait la modification) Séparé en deleterevision et deletelogentry dans la version 1.20 suppress 1.6+
editcontentmodel Modifier le modèle de contenu d’une page - nécessite les droits « edit » user 1.23.7+
editinterface Modifier l’interface utilisateur - contient les messages d'interface. Pour modifier les CSS/JSON/JS partout sur l'ensemble du site, il existe maintenant des droits sélectifs, voir ci-dessous. - nécessite les droits « edit » sysop, interface-admin 1.5+
editmyoptions Modifier vos préférences * 1.22+
editmyprivateinfo Modifier vos données personnelles (par exemple votre adresse, votre vrai nom) et demander des courriels de réinitialisation du mot de passe - masque également Modifier le mot de passe, mais il n'y a pas d'autre manière pour modifier le mot de passe - nécessite les droits viewmyprivateinfo * 1.22+
editmyusercss Modifier vos propres fichiers CSS utilisateur - avant 1.31, il était attribué à tout le monde (c'est-à-dire "*") (notez que cela n'est pas nécessaire si le groupe a déjà le droit editusercss) - nécessite les droits « edit » user 1.22+
editmyuserjs Modifier vos propres fichiers JavaScript utilisateur - avant 1.31, il était attribué à tout le monde (c'est-à-dire "*") (notez que cela n'est pas nécessaire si le groupe a déjà le droit edituserjs) - nécessite les droits « edit » user 1.22+
editmyuserjsredirect Modifier vos propres fichiers JavaScript utilisateur qui sont des redirections (notez-bien que cela n'est pas nécessaire si le groupe possède déjà les droits edituserjs) - nécessite les droits « edit » 1.34+
editmyuserjson Modifier vos propres fichiers JSON utilisateur (notez que cela n'est pas nécessaire si le groupe a déjà le droit edituserjson) - nécessite les droits « edit » user 1.31+
editmywatchlist Modifier votre propre liste de suivi. Remarquez que certaines actions ajouteront encore des pages sans ce droit. - nécessite les droits viewmywatchlist * 1.22+
editsitecss Modifier le CSS du site - nécessite les droits « editinterface » interface-admin 1.32+
editsitejs Modifier le JavaScript du site - nécessite les droits « editinterface » interface-admin 1.32+
editsitejson Modifier le JSON du site - nécessite les droits « editinterface » sysop, interface-admin 1.32+
editusercss Modifier les fichiers CSS des autres utilisateurs - nécessite les droits « edit » interface-admin 1.16+
edituserjs Modifier les fichiers JavaScript des autres utilisateurs - nécessite les droits « edit » interface-admin 1.16+
edituserjson Modifier les fichiers JSON des autres utilisateurs - nécessite les droits « edit » sysop, interface-admin 1.31+
hideuser Bloquer ou débloquer un nom d’utilisateur, en le masquant ou le révélant au public - Seulement les utilisateurs ayant effectué 1000 modifications ou moins peuvent être supprimés par défaut. - nécessite les droits « block »

Utiliser $wgHideUserContribLimit pour désactiver.

suppress 1.10+
markbotedits Marquer des modifications révoquées comme ayant été faites par un robot. - voir Manuel:Révocation - nécessite les droits « rollback » sysop 1.12+
mergehistory Fusionner les historiques des pages - nécessite les droits « edit » sysop 1.12+
pagelang Changer la langue de la page - $wgPageLanguageUseDB doit être à true 1.24+
patrol Marquer les modifications des autres comme étant relues - $wgUseRCPatrol doit être à true sysop 1.5+
patrolmarks Voir les marquages de relecture dans les modifications récentes 1.16+
protect Modifier les paramètres de protection et modifier les pages protégées en cascade - nécessite les droits « edit » sysop 1.5+
rollback Révoquer rapidement les modifications du dernier contributeur d’une page particulière - nécessite les droits « edit » sysop 1.5+
suppressionlog Voir les journaux privés suppress 1.6+
suppressrevision Visualiser, masquer et démasquer des révisions particulières de pages par n’importe quel utilisateur - Avant 1.13 ce droit s’appelait hiderevision - nécessite les droits « deleterevision » suppress 1.6+
unblockself Se débloquer soi-même - Sans cela, un administrateur qui a le droit de bloquer ne peut se débloquer lui-même s'il est bloqué par un autre administrateur sysop 1.17+
undelete Restaurer une page supprimée - nécessite les droits « deletedhistory » sysop 1.12+
userrights Modifier tous les droits d’un utilisateur - permet l'attribution ou la suppression de tous(*) les groupes à n'importe quel utilisateur.

* Avec $wgAddGroups et $wgRemoveGroups vous pouvez rendre possible l'ajout/supression de certains groupes au lieu de tous

bureaucrat 1.5+
userrights-interwiki Modifier les droits des utilisateurs sur d’autres wikis - requires the userrights right 1.12+
viewmyprivateinfo Voir vos données personnelles (par exemple votre adresse, votre vrai nom) * 1.22+
viewmywatchlist Afficher votre propre liste de suivi * 1.22+
viewsuppressed Visualiser les versions masquées de n’importe quel utilisateur - c'est-à-dire une alternative plus étroite à "suppressrevision" (notez que cela n'est pas nécessaire si le groupe a déjà le droit suppressrevision) suppress 1.24+
Administration
autopatrol Avoir ses modifications automatiquement marquées comme relues - $wgUseRCPatrol doit être à « true » bot, sysop 1.9+
deletechangetags Supprimer des balises de la base de données - actuellement non utilisé par les extensions sysop 1.28+
import Importer des pages depuis d’autres wikis - « transwiki » - nécessite les droits « edit » sysop 1.5+
importupload Importer des pages depuis un fichier téléversé - Ce droit est appelé 'importraw' dans la version 1.5 et les précédentes - nécessite les droits « edit » sysop 1.5+
managechangetags Créer et (dés)activer des balises - actuellement inutilisé par les extensions sysop 1.25+
siteadmin Verrouiller ou déverrouiller la base de données - ce qui bloque toute interaction avec le site web sauf l'affichage. (pas disponible par défaut) 1.5+
unwatchedpages Voir la liste des pages non suivies - Liste les pages qui ne sont suivies par personne sysop 1.6+
Technique
apihighlimits Utiliser des limites plus élevées dans les requêtes à l’API bot, sysop 1.12+
autoconfirmed Ne pas être impacté par les limitations de débit liées aux adresses IP - utilisé pour le goupe 'autoconfirmed' , voir l'autre tableau ci-dessous pour davantage d'information (note that this is not needed if the group already has the noratelimit right) autoconfirmed, bot, sysop 1.6+
bot Être traité comme un processus automatisé - peut optionnellement être vu bot 1.5+
ipblock-exempt Éviter les blocages d’adresses ou de plages d’adresses IP et les blocages automatiques sysop 1.9+
nominornewtalk Ne pas déclencher la notification de nouveau message lorsqu’on effectue une modification mineure sur la page de discussion d’un utilisateur - nécessite les droits « minoredit » bot 1.9+
noratelimit Ne pas être affecté par les limites de fréquence - non concerné par les limites de taux (avant l'introduction de ce droit, la variable de configuration $wgRateLimitsExcludedGroups était utilisée pour cela) sysop, bureaucrat 1.13+
override-export-depth Exporter les pages en incluant les pages liées jusqu’à une profondeur de 5 niveaux
Avec ce droit, vous pouvez définir la profondeur des pages liées à Special:Export. Sinon la valeur de $wgExportMaxLinkDepth , qui vaut 0 par défaut, sera utilisée.
?
suppressredirect Ne pas créer de redirection depuis le titre d’origine en renommant les pages - nécessite les droits « move » bot, sysop 1.12+
writeapi Utiliser l'API de modification du wiki - nécessite les droits edit *, user, bot 1.13+
Bien que toutes ces permissions contrôlent des choses distinctes, quelques fois, pour réaliser certaines actions, vous avez besoin de permissions multiples. Par exemple, autoriser les gens à modifier sans leur donner l'accès en lecture n'a pas de sens, car pour modifier une page vous devez d'abord pouvoir la lire (en supposant qu'aucune page ne soit en liste blanche). Autoriser les téléversements sur le serveur, mais ne pas autoriser les modifications n'a pas de sens, car pour pouvoir téléverser une image vous devez implicitement créer une page de description d'image, etc...

Liste des groupes

Les groupes suivants sont disponibles dans la dernière version de MediaWiki. Si vous utilisez une ancienne version, certains d'entre-eux pourraient ne pas être implémentés.

Groupe Description Permissions par défault Versions
* tous les utilisateurs (anonymes y compris). createaccount, createpage, createtalk, edit, editmyoptions, editmyprivateinfo, editmywatchlist, read, viewmyprivateinfo, viewmywatchlist, writeapi 1.5+
temp Temporary user accounts (T330816) Similar to * group 1.41+
user utilisateurs enregistrés. applychangetags, changetags, createpage, createtalk, edit, editcontentmodel, editmyusercss, editmyuserjs, editmyuserjson, minoredit, move, move-categorypages, move-rootuserpages, move-subpages, movefile, purge, read, reupload, reupload-shared, sendemail, upload, writeapi
autoconfirmed utilisateurs enregistrés depuis

au moins $wgAutoConfirmAge et ayant fait au moins $wgAutoConfirmCount modifications.

autoconfirmed, editsemiprotected 1.6+
bot comptes avec le droit bot (prévu pour les scripts automatiques). autoconfirmed, autopatrol, apihighlimits, bot, editsemiprotected, nominornewtalk, suppressredirect, writeapi 1.5+
sysop utilisateurs pouvant par défaut supprimer/restaurer des pages, bloquer/débloquer des utilisateurs, etc... apihighlimits, autoconfirmed, autopatrol, bigdelete, block, blockemail, browsearchive, createaccount, delete, deletedhistory, deletedtext, editinterface, editprotected, editsemiprotected, editsitejson, edituserjson, import, importupload, ipblock-exempt, managechangetags, markbotedits, mergehistory, move, move-categorypages, move-rootuserpages, move-subpages, movefile, noratelimit, patrol, protect, reupload, reupload-shared, rollback, suppressredirect, unblockself, undelete, unwatchedpages, upload 1.5+
interface-admin utilisateurs pouvant modifier les CSS/JS partout sur le site. editinterface, editsitecss, editsitejs, editsitejson, editusercss, edituserjs, edituserjson 1.32+
bureaucrat utilisateurs pouvant par défaut modifier les droits d'autres utilisateurs. noratelimit, userrights 1.5+
suppress deletelogentry, deleterevision, hideuser, suppressionlog, suppressrevision, viewsuppressed

Depuis MW 1.12, vous pouvez créer vos propres groupes dans lesquels les utilisateurs sont automatiquement promus (comme c'est le cas pour « autoconfirmed » et « emailconfirmed ») en utilisant $wgAutopromote . Vous pouvez même créer n'importe quel groupe personnalisé, juste en lui assignant des droits.

Droits par défaut

Les droits par défaut sont définis dans DefaultSettings.php .

Ajouter de nouveaux droits

Les informations ci-après ne concernent que les développeurs.

Si vous ajoutez une nouvelle permission dans le noyau, par exemple pour contrôler une nouvelle page spéciale, vous devez l'ajouter à la liste des droits disponibles dans PermissionManager.php , $coreRights (exemple). Si vous faites cela dans une extension , vous aurez besoin d'utiliser $wgAvailableRights .

Probablement vous voudrez l'affecter à un groupe d'utilisateurs en modifiant $wgGroupPermissions décrit ci-dessus.

Si vous voulez que ce droit soit accessible pour les applications externes par OAuth  ou par les mots de passe des robots, alors vous devrez l'ajouter à une permission en mettant à jour $wgGrantPermissions .

// déclarer les droits des membres du projet
$wgAvailableRights[] = 'projectmember-powers';

// ajouter les droits du projet projectmember au groupe projectmember-group
$wgGroupPermissions['projectmember']['projectmember-powers'] = true;

// ajouter les droits de projectmember aux droits 'de base' de sorte à pouvoir utiliser les droits de projectmember lors d'une requête d'API
$wgGrantPermissions['basic']['projectmember-powers'] = true;

Vous devez aussi ajouter les messages d'interface right-[name] et action-[name] dans /languages/i18n/en.json (avec la documentation dans qqq.json). Les messages right-* peuvent être vus sur Special:ListGroupRights et les messages action-* sont utilisés dans une phrase telle que Vous n'avez pas la permission de ....

Voir aussi