PhpBB Lab Académie

Prévoir les droits d’un membre appartenant à plusieurs groupes, distinguer les portées et choisir un modèle adapté avant toute modification.

Une permission répond à une question précise
Les catégories, les forums et les groupes existent maintenant. Ils n’indiquent pas encore qui peut lire ou écrire. Une permission est une autorisation portant sur une action : voir un forum, consulter son contenu, créer un sujet, répondre, ou modérer un message. Nous allons donner des droits aux groupes ; phpBB calculera ensuite les droits de chaque membre à partir de ses appartenances.

Votre règle de travail est : « Qui ? Sur quel espace ? Pour quelle action ? » Dans notre projet, « l’équipe peut publier dans Annonces » devient une attribution au groupe Équipe de l’association, sur le forum Annonces, concernant notamment la création de sujets. Le nom du forum n’impose aucun droit. Un groupe Fermé contrôle l’admission de ses membres ; ce statut ne lui ouvre aucun forum.

Les trois valeurs
Oui accorde la permission. Non ne l’accorde pas à cet endroit, mais laisse un autre groupe l’accorder. Jamais interdit la permission et l’emporte sur les Oui provenant des autres groupes pour cette même permission locale. Sans aucun Oui utilisable, l’action reste refusée. Non n’est donc pas une autorisation implicite ; c’est une absence d’autorisation qui reste compatible avec un Oui ailleurs.

Appliquez cette règle séparément à chaque action et à chaque forum. Pour « Peut consulter ce forum. », Non dans Utilisateurs enregistrés et Oui dans Adhérents de l’association donnent Oui à un adhérent. Remplacez le premier Non par Jamais : ce même adhérent ne peut plus consulter le forum. Ajouter encore un groupe avec Oui ne réparera pas le blocage. Il faudra corriger le Jamais à sa source.

Cette règle décrit nos permissions de forums. Ne l’utilisez pas pour mélanger sans distinction administration, permissions globales et modération locale. Ces familles ont des portées différentes ; notamment, une autorisation de modération globale ne constitue pas une attribution limitée à un seul forum.

Un compte conserve ses autres groupes
eleve_test est à la fois Utilisateur enregistré et membre d’Adhérents de l’association. equipe_test est Utilisateur enregistré et membre des deux groupes associatifs. Le groupe par défaut sert notamment à la présentation du membre ; il ne remplace pas ses autres appartenances dans le calcul des permissions. Vous ne devez pas retirer un membre d’Utilisateurs enregistrés pour lui ouvrir un espace privé.

Dans Coordination, nous souhaitons refuser l’accès à eleve_test et l’autoriser à equipe_test. Nous mettrons donc les droits de lecture à Non pour Adhérents de l’association, et à Oui pour Équipe de l’association. Un Jamais sur Adhérents bloquerait equipe_test, puisqu’il appartient également à ce groupe. L’absence de droit général, complétée par un droit du groupe spécialisé, suffit à construire cet espace privé.

Les familles de permissions
Les Permissions des forums déterminent l’accès et la participation sur les espaces sélectionnés. Les Permissions des modérateurs donnent des outils de gestion des sujets et messages sur les forums concernés. Les Permissions des modérateurs globaux ont une portée générale. Les Permissions d’administration donnent accès à des fonctions du panneau d’administration. Enfin, les Permissions de l’utilisateur concernent des fonctionnalités telles que le profil ou la messagerie privée.

Ces distinctions évitent une erreur fréquente : accorder de l’administration pour réparer une difficulté de lecture. CamilleAdmin sert à la configuration ; les trois comptes de vérification restent ordinaires. À la dernière leçon seulement, equipe_test recevra des droits de modération par son groupe, exclusivement dans Questions publiques.

Un modèle est un ensemble de réglages
Le champ de l’interface s’appelle Modèle. Choisir « Accès en lecture uniquement » prépare les autorisations nécessaires à la lecture, sans créer de sujets ni répondre. « Accès standard » permet la participation ordinaire. « Aucun accès » ne donne aucun droit de lecture ou de publication ; dans les Permissions avancées, les permissions détaillées de ce modèle sont sur Non. Ce modèle permet donc à un autre groupe d’accorder ses Oui. Ne le remplacez pas par « Tous sur JAMAIS ».

« Aucun modèle assigné… » n’a pas le même sens qu’« Aucun accès » : sélectionner cette absence de modèle ne remet pas automatiquement toutes les permissions à Non. Pour neutraliser explicitement un ensemble de réglages personnalisés, il existe « Tous sur NON ». Nous privilégierons les modèles pour rendre les attributions lisibles.

Un modèle assigné est partagé. Modifier sa définition dans Modèles de forum peut changer les droits de plusieurs groupes et forums qui l’utilisent. Dans ce cours, nous utilisons les modèles existants sans modifier leur définition. Copier plus tard les permissions d’un forum sera une autre opération : la destination recevra les attributions du moment, sans suivre les changements d’attribution du forum source.

Avant de régler
Sur http://localhost/forum-ecole/, connectez-vous avec CamilleAdmin, puis ouvrez le Panneau d’administration. Dans Permissions, repérez « Permissions groupes/forums » et « Modérateurs des forums ». Le premier sera notre entrée habituelle pour les droits d’accès ; le second servira à la délégation locale. Lisez les titres des pages : plusieurs menus emploient des mots proches.

Les trois comptes préparés au chapitre précédent ont quitté le statut Nouveaux utilisateurs enregistrés. Pour d’autres comptes, ce groupe peut encore apporter des restrictions : son modèle « Accès nouvel utilisateur enregistré » comporte notamment un Jamais sur « Peut poster sans approbation. ». Cela impose une validation des messages même si un autre groupe possède Oui. Il ne faut pas confondre une attente d’approbation avec l’absence de droit de lecture.

Trois calculs dans Coordination
inscrit_test n’a que des groupes qui n’accordent pas la lecture : il ne peut pas entrer. eleve_test possède en plus Adhérents de l’association, réglé sur Non : son résultat reste refusé. equipe_test possède aussi Équipe de l’association, qui apporte Oui : il peut entrer.

Si vous inscrivez ensuite equipe_test comme groupe par défaut Adhérents de l’association, ses droits restent calculés avec les deux groupes. Si vous lui retirez réellement son appartenance à Équipe de l’association, le Oui disparaît et l’accès est perdu. Présentation et appartenance sont deux opérations différentes.

Sans enregistrer de changement, répondez dans vos notes aux quatre situations suivantes.
1. Dans Vie de l’association, Utilisateurs enregistrés vaut Non et Adhérents de l’association vaut Oui : eleve_test peut-il lire ?
2. Même situation, mais Utilisateurs enregistrés vaut Jamais : que faut-il corriger ?
3. L’équipe doit répondre aux visiteurs dans Questions publiques : quelle famille règle la participation ordinaire ?
4. Vous voulez priver un groupe de ses propres autorisations tout en laissant agir celles d’autres groupes : choisissez-vous « Aucun accès », « Aucun modèle assigné… » ou « Tous sur JAMAIS » ?

Repérez ensuite Permissions groupes/forums dans le PCA, puis revenez à l’accueil du PCA. Cette première exploration ne doit modifier aucun modèle ni aucune attribution.

Une permission se lit avec son groupe, son forum et son action. Dans nos réglages locaux, Oui accorde, Non laisse un autre groupe accorder, Jamais bloque. Les groupes se cumulent. Un modèle rassemble des réglages ; sa définition partagée ne doit pas être modifiée pour résoudre une exception locale.