phpBB Lab

Permissions des groupes phpBB : comprendre les droits, rôles et conflits entre groupes

Dans phpBB, les groupes ne servent pas seulement à ranger les utilisateurs.

Ils sont aussi l’un des principaux mécanismes utilisés pour leur attribuer des permissions.

Un membre peut appartenir à plusieurs groupes en même temps.

Chacun de ces groupes peut lui apporter des droits différents.

Et c’est précisément là que beaucoup d’administrateurs commencent à se perdre.

Pourquoi un utilisateur possède-t-il une permission alors qu’elle n’est pas activée dans son groupe principal ?

Pourquoi un autre utilisateur reste-t-il bloqué alors qu’un groupe lui donne explicitement le droit ?

Pourquoi modifier un groupe peut-il affecter des dizaines ou des centaines de comptes d’un seul coup ?

Ce guide va reprendre le fonctionnement depuis le début afin de comprendre réellement :

• []à quoi servent les groupes dans le système de permissions ;
  []ce qu’est une permission de groupe ;
  []la différence entre permissions globales et permissions liées aux forums ;
  []comment plusieurs groupes peuvent cumuler leurs droits ;
  []comment fonctionnent Oui, Non et Jamais ;
  []à quoi servent les rôles ;
  []pourquoi le groupe principal n’est pas le seul groupe important ;
  []comment diagnostiquer un conflit de permissions ;

• et comment organiser les groupes sans transformer les permissions en casse-tête.

1. Un groupe n’est pas seulement une liste de membres

Dans phpBB, un groupe peut servir à plusieurs choses.

Il peut notamment :

• []regrouper plusieurs utilisateurs ;
  []attribuer une couleur ou certains éléments de présentation ;
  []faciliter l’organisation des membres ;
  []attribuer des permissions ;
  []donner accès à certaines parties du forum ;
  []accorder des fonctions particulières ;

• ou au contraire limiter certaines possibilités.

Prenons un exemple simple :

Utilisateurs enregistrés
Testeurs
Équipe technique
Modérateurs

Un même utilisateur pourrait appartenir aux quatre groupes.

Ses permissions finales ne seront donc pas forcément celles d’un seul de ces groupes.

phpBB doit prendre en compte l’ensemble des permissions applicables.

2. Le principe le plus important : les permissions s’additionnent

Imaginons un utilisateur appartenant à deux groupes.

Utilisateurs enregistrés
Testeurs

Le groupe Utilisateurs enregistrés ne lui donne pas une permission particulière.

Le groupe Testeurs, lui, lui accorde cette permission.

Dans de nombreux cas, le résultat final sera que l’utilisateur possède bien cette permission.

On peut représenter cela ainsi :

Utilisateurs enregistrés : Non
Testeurs : Oui

Résultat : Oui

C’est une notion essentielle.

Un utilisateur ne reçoit pas uniquement les permissions de son groupe principal.

Toutes ses appartenances peuvent intervenir.

3. Groupe principal et permissions : attention à la confusion

Chaque utilisateur peut avoir un groupe principal.

Mais cela ne signifie pas :

Seules les permissions du groupe principal comptent.

C’est faux.

Le groupe principal est important pour certains éléments de fonctionnement et de présentation, mais un utilisateur peut recevoir des permissions depuis plusieurs groupes auxquels il appartient.

Par exemple :

Groupe principal :
Utilisateurs enregistrés

Autres groupes :
Testeurs
Développeurs
Modérateurs

Les permissions de Testeurs, Développeurs et Modérateurs peuvent tout à fait influencer les droits réels de cet utilisateur.

4. Les groupes prédéfinis de phpBB

Une installation classique de phpBB possède déjà plusieurs groupes spéciaux.

Selon la langue et la personnalisation du forum, vous trouverez notamment des groupes correspondant à :

• []l’administration ;
  []la modération globale ;
  []les utilisateurs enregistrés ;
  []les nouveaux utilisateurs ;
  []les visiteurs ;
  []les robots.

Ces groupes ont chacun un rôle particulier.

Il est généralement préférable de comprendre leur fonction avant de modifier leurs permissions en profondeur.

Un changement appliqué au groupe des utilisateurs enregistrés peut par exemple affecter presque tous les membres du forum.

5. Un changement de permission de groupe peut avoir un impact très large

Supposons que votre forum possède 5 000 membres.

Tous appartiennent au groupe :

Utilisateurs enregistrés

Si vous modifiez une permission de ce groupe, vous ne modifiez pas un seul utilisateur.

Vous pouvez modifier le comportement de milliers de comptes.

C’est l’un des grands avantages des groupes :

une seule configuration permet de gérer beaucoup d’utilisateurs.

Mais c’est aussi une raison d’être prudent.

6. Permissions globales et permissions de forum : ce n’est pas la même chose

C’est probablement la confusion la plus fréquente.

Dans phpBB, certaines permissions concernent le forum dans son ensemble.

D’autres concernent un forum particulier.

Par exemple, une permission globale peut porter sur une fonctionnalité générale disponible pour un groupe.

Une permission de forum concerne une section précise.

Il faut donc distinguer :

Permissions globales du groupe

et :

Permissions du groupe dans un forum précis

Ce sont deux niveaux différents.

7. Exemple : un groupe peut avoir des droits généraux sans avoir accès à un forum

Prenons un groupe :

Testeurs

Vous lui accordez certaines possibilités globales.

Mais le forum :

Zone privée de développement

n’autorise pas ce groupe à entrer.

Les membres du groupe Testeurs pourront donc posséder leurs permissions globales tout en restant exclus de ce forum particulier.

Cela n’a rien de contradictoire.

Les deux systèmes ne répondent simplement pas à la même question.

8. La bonne question à se poser

Lorsque vous configurez les permissions d’un groupe, demandez-vous d’abord :

 Est-ce que je configure un droit général,
ou un droit concernant un forum précis ?

Cette question évite énormément d’erreurs.

Si votre objectif est :

Ce groupe doit pouvoir entrer dans le forum Bêta.

vous travaillez sur une permission liée au forum.

Si votre objectif est :

Les membres de ce groupe doivent disposer d’une capacité générale particulière.

vous regardez les permissions globales appropriées.

9. Où gérer les permissions des groupes ?

Dans le Panneau d’administration, rendez-vous dans la section consacrée aux Permissions.

phpBB propose plusieurs écrans.

Vous pouvez notamment gérer les permissions en partant :

• []des groupes ;
  []des utilisateurs ;
  []des forums ;
  []des administrateurs ;
  []des modérateurs ;
  []ou des permissions spécifiques aux forums.

Il faut donc choisir l’écran correspondant réellement à votre objectif.

Ne modifiez pas une permission simplement parce que vous voyez le nom du groupe quelque part.

10. Commencer par définir le rôle du groupe

Avant de toucher aux réglages, écrivez mentalement ce que le groupe doit représenter.

Exemple :

Groupe Testeurs

Mission :
tester les nouvelles fonctionnalités.

Doit pouvoir :

* accéder à la zone bêta ;
* lire les sujets ;
* publier des retours.

Ne doit pas pouvoir :

* administrer le forum ;
* modérer les autres sections ;
* modifier la configuration générale.
    

Avec cet objectif clairement défini, les permissions deviennent beaucoup plus faciles à choisir.

11. Mauvaise méthode : donner des droits jusqu’à ce que cela fonctionne

Une mauvaise pratique fréquente consiste à faire ceci :

Ça ne fonctionne pas.

Je mets Oui ici.
Toujours pas.

Je mets encore Oui là.
Toujours pas.

Je donne davantage de permissions.

Au bout de quelques essais, la fonctionnalité finit éventuellement par fonctionner.

Mais personne ne sait plus pourquoi.

Quelques mois plus tard, le groupe possède des droits qu’il n’aurait jamais dû avoir.

La bonne méthode consiste à identifier précisément la permission nécessaire.

12. Comprendre Oui

Dans le système de permissions phpBB :

Oui

signifie qu’une source de permissions accorde le droit.

Exemple :

Groupe Testeurs
Permission X : Oui

Le groupe Testeurs apporte donc cette permission à ses membres.

13. Comprendre Non

Non

est souvent mal interprété.

Beaucoup pensent :

Non = interdit quoi qu’il arrive.

Ce n’est généralement pas la bonne manière de le comprendre.

Dans beaucoup de situations, Non signifie plutôt :

Ce groupe n’accorde pas cette permission.

Un autre groupe peut éventuellement l’accorder.

Exemple :

Utilisateurs enregistrés : Non
Testeurs : Oui

Le membre appartenant aux deux groupes pourra recevoir la permission grâce au groupe Testeurs.

14. Comprendre Jamais

Jamais

est beaucoup plus puissant.

Il représente une interdiction forte.

Prenons :

Utilisateurs enregistrés : Oui
Utilisateurs restreints : Jamais

Un membre appartenant aux deux groupes peut rester bloqué à cause du Jamais.

C’est souvent la source des problèmes les plus difficiles à comprendre.

15. Pourquoi Jamais doit rester exceptionnel

Il peut être tentant de mettre Jamais partout lorsqu’on souhaite refuser quelque chose.

Mais ce choix rend les permissions beaucoup plus rigides.

Supposons que vous créez plus tard un groupe :

Membres de confiance

et que vous lui accordez Oui.

Si ces utilisateurs appartiennent également à un groupe contenant Jamais, votre nouveau Oui peut ne pas produire l’effet attendu.

Vous allez alors chercher longtemps un problème qui vient simplement d’un ancien Jamais oublié.

16. Une règle pratique

Gardez cette idée en tête :

Oui = j’accorde.
Non = je n’accorde pas ici.
Jamais = je veux bloquer fortement. 

Ce n’est pas une description de tous les détails internes du moteur de permissions, mais c’est une excellente manière de raisonner lorsqu’on administre un forum.

17. Exemple avec trois groupes

Un utilisateur appartient à :

Utilisateurs enregistrés
Testeurs
Développeurs

Pour une permission particulière :

Utilisateurs enregistrés : Non
Testeurs : Oui
Développeurs : Non

Le groupe Testeurs apporte Oui.

Le résultat final peut donc être Oui.

Mais changeons légèrement la situation :

Utilisateurs enregistrés : Non
Testeurs : Oui
Développeurs : Jamais

Le Jamais du groupe Développeurs peut maintenant bloquer la permission.

C’est pour cela qu’il faut toujours regarder toutes les appartenances.

18. Les rôles simplifient énormément la gestion

phpBB dispose de rôles de permissions.

Un rôle correspond à un ensemble cohérent de réglages.

Au lieu de régler manuellement de nombreuses permissions une par une, vous pouvez attribuer un rôle adapté au groupe.

C’est beaucoup plus facile à maintenir.

Imaginez un rôle contenant :

Permission A : Oui
Permission B : Oui
Permission C : Non
Permission D : Oui
…

Vous pouvez appliquer cet ensemble sans reconstruire chaque règle manuellement.

19. Pourquoi utiliser un rôle plutôt que tout régler à la main ?

Pour trois raisons principales.

Première raison : la lisibilité

Vous comprenez immédiatement le niveau de permission général appliqué.

Deuxième raison : la cohérence

Deux groupes ayant le même besoin peuvent recevoir le même rôle.

Troisième raison : la maintenance

Vous évitez de créer des dizaines de configurations légèrement différentes sans savoir pourquoi.

20. Les permissions avancées restent utiles

Les rôles ne suffisent pas toujours.

Supposons que votre groupe :

Contributeurs

doive avoir presque les mêmes droits qu’un groupe classique, sauf une fonctionnalité précise.
Vous pouvez partir d’une base cohérente puis examiner les permissions avancées.

L’important est de savoir exactement pourquoi vous faites cette exception.

21. Éviter les groupes qui font tout

Un groupe nommé :

VIP

auquel on ajoute progressivement :

• []des droits de forum ;
  []des permissions globales ;
  []des fonctions de modération ;
  []des privilèges administratifs ;
  []des accès privés ;
  []des exceptions diverses ;

peut rapidement devenir impossible à comprendre.

Une meilleure approche consiste parfois à séparer les responsabilités.

Par exemple :

Testeurs
Contributeurs
Modérateurs
Équipe technique

Un utilisateur peut appartenir à plusieurs groupes si nécessaire.

22. Un groupe doit avoir une fonction claire

Si vous ne savez plus répondre à cette question :

À quoi sert exactement ce groupe ?

il est probablement temps de revoir son organisation.

Un bon groupe pourrait avoir une définition simple :

Testeurs :
accès aux forums de test.

Modérateurs :
gestion des discussions.

Contributeurs :
accès aux outils réservés aux contributeurs.

Équipe :
accès à la zone interne.

Plus la mission est claire, plus les permissions seront faciles à comprendre.

23. Le groupe des utilisateurs enregistrés mérite une attention particulière

Presque tous les membres ordinaires appartiennent à ce groupe.

Il constitue donc souvent une sorte de socle commun.

Vous pouvez considérer son rôle comme :

Droits de base d’un membre normal.

Les groupes supplémentaires apportent ensuite des possibilités particulières.

Par exemple :

Utilisateur enregistré
+
Testeur

membre normal + accès aux fonctions de test

Cette façon de penser est généralement beaucoup plus simple que d’essayer de recréer toutes les permissions dans chaque groupe supplémentaire.

24. Exemple d’organisation cohérente

Imaginons les groupes suivants :

Utilisateurs enregistrés
Débutants
Testeurs
Modérateurs
Équipe technique

On peut leur donner une logique claire.

Utilisateurs enregistrés
= droits normaux d’un membre

Débutants
= restrictions temporaires supplémentaires

Testeurs
= accès aux espaces de test

Modérateurs
= fonctions de modération

Équipe technique
= accès aux zones techniques internes

Chaque groupe ajoute ou ajuste une fonction identifiable.

25. Les nouveaux utilisateurs peuvent appartenir à plusieurs groupes

Dans une configuration utilisant un groupe pour les nouveaux membres, un utilisateur peut appartenir simultanément à :

Utilisateurs enregistrés
Nouveaux utilisateurs

C’est parfaitement normal.

Cela permet à phpBB de conserver les droits de base du membre tout en lui appliquant temporairement certaines restrictions supplémentaires.

Lorsque la condition prévue par la configuration du forum est remplie, son appartenance au groupe des nouveaux utilisateurs peut évoluer.

26. C’est un bon exemple de l’utilité de Jamais

Certaines restrictions fortes peuvent justement nécessiter qu’un groupe temporaire empêche une permission normalement accordée par le groupe général.

C’est l’un des cas où la logique d’interdiction forte peut avoir du sens.

Le problème n’est donc pas que Jamais existe.

Le problème est de l’utiliser partout sans savoir pourquoi.

27. Permissions administratives et appartenance au groupe Administrateurs

Une erreur fréquente consiste à penser :

Il est dans le groupe Administrateurs,
donc tout est forcément autorisé partout.

Il faut distinguer plusieurs familles de permissions.

Les fonctions d’administration sont une chose.

Les permissions de forum en sont une autre.

La modération en est encore une autre.

Lorsqu’un problème concerne une action précise, recherchez la permission correspondant réellement à cette action.

28. Même principe pour les modérateurs

Être membre d’un groupe de modération ne signifie pas nécessairement que toutes les permissions possibles sont accordées partout sans distinction.

Il faut considérer :

• []les permissions globales éventuelles ;
  []les permissions de modération ;
  []les forums concernés ;
  []les autres groupes auxquels appartient l’utilisateur.

Le mot modérateur ne remplace pas le système de permissions.

29. Le danger des permissions individuelles ajoutées par-dessus les groupes

phpBB permet également d’attribuer des permissions directement à certains utilisateurs.

Cela peut être utile dans des cas particuliers.

Mais imaginez cette situation :

Le groupe Testeurs possède une configuration.
Le groupe Développeurs en possède une autre.
L’utilisateur Michel possède également une exception individuelle.

Pour comprendre ses droits réels, vous devez maintenant examiner trois sources différentes.

Plus vous multipliez les exceptions individuelles, plus le diagnostic devient complexe.

30. Bonne pratique : commencer par les groupes

Si plusieurs utilisateurs doivent obtenir les mêmes droits, créez ou utilisez un groupe.

Exemple :

Mauvaise logique :

Donner individuellement l’accès bêta à :
Utilisateur A
Utilisateur B
Utilisateur C
Utilisateur D
Utilisateur E

Meilleure logique :

Groupe : Testeurs bêta

Membres :
Utilisateur A
Utilisateur B
Utilisateur C
Utilisateur D
Utilisateur E

Puis attribuez les permissions au groupe.

31. Un utilisateur a trop de droits : comment chercher ?

Ne retirez pas immédiatement des permissions au hasard.

Procédez méthodiquement.

Étape 1

Identifiez précisément le droit inattendu.

Exemple :

Cet utilisateur peut effectuer l’action X.

Étape 2

Listez ses groupes.

Étape 3

Examinez les permissions correspondant à cette action dans chacun de ces groupes.

Étape 4

Vérifiez s’il possède également une permission individuelle.

Étape 5

Examinez la permission réellement calculée.

Étape 6

Corrigez la source du droit au lieu de masquer simplement le résultat.

32. Un utilisateur n’a pas assez de droits : même méthode

Supposons qu’il devrait pouvoir utiliser une fonction mais que phpBB la refuse.

Vérifiez :

• []à quels groupes il appartient ;
  []quel groupe est censé lui accorder la permission ;
  []si cette permission est réellement sur Oui ;
  []si une autre appartenance impose Jamais ;
  []si une permission individuelle intervient ;
  []si le problème dépend en réalité d’un forum particulier.

Ne concluez pas trop vite :

Le groupe est mal configuré.

Le problème peut venir d’une autre source.

33. Les permissions effectives sont votre meilleur outil de diagnostic

Quand les choses deviennent confuses, ne vous contentez pas de parcourir les écrans en cherchant un Oui ou un Non.

L’objectif doit être de connaître :

la permission finale obtenue par cet utilisateur.

Les outils de traçage et de consultation des permissions permettent justement de comprendre pourquoi un droit est accordé ou refusé.

C’est beaucoup plus efficace que de modifier les réglages à l’aveugle.

34. Exemple de conflit typique

Vous créez un groupe :

Rédacteurs

Vous lui donnez :

Permission de publication spéciale : Oui

Mais un membre du groupe ne peut toujours pas publier.

Vous contrôlez le groupe Rédacteurs :

Oui

Tout semble correct.

Vous découvrez finalement que le même utilisateur appartient également à :

Utilisateurs restreints

et que ce groupe possède :

Permission de publication spéciale : Jamais

Le problème ne se trouvait donc pas dans le groupe Rédacteurs.

Il se trouvait dans le cumul des groupes.

35. Tester avec un compte représentatif

Après une modification importante, ne testez pas seulement avec votre propre compte administrateur.

Testez avec un utilisateur appartenant réellement au groupe concerné.

Par exemple :

Compte de test :

* Utilisateurs enregistrés
* Testeurs
    

Vous verrez immédiatement le comportement réel.

Un compte administrateur possède souvent tellement de droits supplémentaires qu’il constitue un mauvais témoin pour vérifier les permissions ordinaires.

36. Ne pas modifier un groupe important sans mesurer l’impact

Avant de modifier :

Utilisateurs enregistrés

ou un autre groupe contenant beaucoup de membres, demandez-vous :

• []combien d’utilisateurs seront affectés ;
  []si le changement concerne tout le forum ou seulement une section ;
  []si une permission de forum serait plus appropriée ;
  []si un nouveau groupe spécialisé serait préférable.

Ne transformez pas une exception concernant dix utilisateurs en changement global concernant tout le forum.

37. Exemple : dix membres ont besoin d’une fonction supplémentaire

Vous avez 2 000 utilisateurs enregistrés.
Dix personnes doivent avoir accès à une fonctionnalité particulière.

Mauvaise solution :

Modifier le groupe Utilisateurs enregistrés.

Bonne logique :

Créer ou utiliser un groupe spécifique.
Ajouter les dix utilisateurs.
Attribuer la permission au groupe.

Cela permet de conserver une configuration claire et réversible.

38. Garder une organisation simple

Il est possible de créer énormément de groupes.

Cela ne signifie pas qu’il faut le faire.

Une structure comme :

Groupe spécial 1
Groupe spécial 2
Groupe spécial 3
VIP 1
VIP 2
Membres avancés
Membres très avancés
Équipe spéciale
Équipe spéciale 2

devient rapidement incompréhensible.

Préférez quelques groupes dont le rôle est clairement défini.

39. Documenter les groupes inhabituels

Si vous créez un groupe particulier, notez sa fonction.

Par exemple :

Testeurs bêta :
accès temporaire aux espaces de test.

Contributeurs documentation :
accès à la préparation des guides.

Équipe technique :
accès aux discussions internes de développement.

Six mois plus tard, vous saurez toujours pourquoi le groupe existe.

40. Méthode simple avant toute modification

Pour éviter les erreurs, utilisez toujours ce raisonnement :

1. Quel utilisateur ou quelle catégorie d’utilisateurs est concerné ?
2. Quelle action doit être autorisée ou refusée ?
3. Est-ce une permission globale ou liée à un forum ?
4. Quel groupe devrait normalement apporter cette permission ?
5. Quels autres groupes peuvent influencer le résultat ?
6. Existe-t-il un Jamais ?
7. Quelle est la permission effective ?
8. Quelle est la plus petite modification nécessaire ?
    

Cette méthode évite une grande partie des problèmes de permissions.

41. Ce qu’il faut éviter

Évitez notamment :

• []de mettre Jamais partout ;
  []de modifier des permissions sans savoir à quoi elles correspondent ;
  []de considérer uniquement le groupe principal ;
  []d’oublier qu’un utilisateur peut appartenir à plusieurs groupes ;
  []de mélanger permissions globales et permissions de forum ;
  []de donner individuellement les mêmes droits à des dizaines d’utilisateurs ;
  []de multiplier les groupes sans fonction précise ;
  []de tester uniquement avec un compte administrateur ;

• de changer plusieurs permissions simultanément pendant un diagnostic.

42. La philosophie qui simplifie tout

Pensez les groupes comme des ensembles de responsabilités.

Par exemple :

Utilisateurs enregistrés
= socle normal

Testeurs
= capacité supplémentaire de test

Modérateurs
= responsabilités de modération

Équipe technique
= accès et fonctions techniques

Groupe restreint
= limitations particulières

Ensuite, laissez phpBB combiner ces responsabilités.

Cette manière de construire les groupes est beaucoup plus facile à maintenir que de créer un groupe complet différent pour chaque combinaison possible d’utilisateurs.

En résumé

Pour bien comprendre les permissions des groupes dans phpBB, retenez surtout ceci :

• []Un utilisateur peut appartenir à plusieurs groupes en même temps.
  []Le groupe principal n’est pas la seule source de permissions.
  []Les permissions de plusieurs groupes peuvent se combiner.
  []Oui accorde une permission.
  []Non signifie généralement que cette source ne l’accorde pas.
  []Jamais constitue une interdiction forte et doit rester maîtrisé.
  []Les permissions globales et les permissions liées aux forums sont deux choses différentes.
  []Les rôles permettent d’appliquer des ensembles cohérents de droits.
  []Il vaut généralement mieux gérer les permissions par groupes que multiplier les exceptions individuelles.
  []Un groupe doit avoir une fonction claire.

• Pour diagnostiquer un problème, il faut examiner l’ensemble des groupes de l’utilisateur et sa permission effective.

Le système de permissions de phpBB paraît compliqué lorsqu’on observe chaque case séparément.
Il devient beaucoup plus logique lorsqu’on comprend que phpBB cherche en réalité à répondre à une seule question :

Compte tenu de tous les groupes auxquels appartient cet utilisateur, quels droits possède-t-il finalement ?