Important : cette organisation est une bonne pratique documentée par TYPO3, mais elle n’est pas imposée par le Core. TYPO3 précise explicitement que cette classification doit être considérée comme une ligne directrice plutôt que comme un standard obligatoire.

Pour suivre cette procédure, vous devez disposer de :

• TYPO3 13.4 LTS ou TYPO3 14.3 LTS;
• un compte administrateur TYPO3;
• l’accès à la gestion des utilisateurs et groupes backend;
• une compréhension générale des permissions actuellement utilisées sur le projet.

Dans TYPO3 13.4, les groupes sont accessibles dans System > Backend Users, puis dans Backend User Groups.

Dans TYPO3 14, le module a été réorganisé sous Administration > Users, puis Backend User Groups.

TYPO3 propose de distinguer trois grandes familles de groupes :

System Groups

Les System Groups définissent principalement l’étendue du système à laquelle un utilisateur peut accéder : pages, arborescences, fichiers, catégories ou autres montages.

Ils constituent les briques de base des permissions.

Exemples :

• accès à une branche de pages;
• DB Mount;
• File Mount;
• Category Mount.

Access Control List Groups

Les Access Control List Groups, ou groupes ACL, déterminent plutôt ce qu’un utilisateur peut faire.

Ils peuvent notamment contrôler :

• les modules backend accessibles;
• les types de contenu;
• les tables pouvant être consultées ou modifiées;
• certains champs d’un formulaire;
• les widgets;
• des fonctionnalités fournies par des extensions.

Un groupe ACL devrait idéalement représenter une capacité fonctionnelle précise et réutilisable.

Role Groups

Les Role Groups correspondent aux rôles réels occupés par les utilisateurs, par exemple :

• éditeur de contenu;
• éditeur avancé;
• réviseur;
• responsable des actualités;
• gestionnaire d’un site.

Un Role Group regroupe plusieurs groupes techniques grâce à l’héritage.

TYPO3 recommande qu’un Role Group n’ait pas de permissions configurées directement : il devrait obtenir ses droits en héritant de sous-groupes.

Par exemple :

R_content_editor
├── PG_site_principal
├── DBM_site_principal
├── FM_site_principal
├── FO_read_write
├── L_fr_en
├── ACL_content
└── ACL_news

Cette approche rend les permissions beaucoup plus faciles à comprendre, à réutiliser et à faire évoluer.

1. Faites l’inventaire des groupes existants

Ouvrez la liste des groupes backend.

Dans TYPO3 13.4 :

System > Backend Users > Backend User Groups

Dans TYPO3 14.3 :

Administration > Users > Backend User Groups

TYPO3 permet depuis ce module de consulter, modifier, désactiver, supprimer et comparer les groupes backend.

Pour chaque groupe existant, déterminez sa fonction réelle.

Par exemple :

Ne commencez pas immédiatement à modifier les permissions. L’objectif de cette première étape est de comprendre ce que chaque groupe fait actuellement.

Capture d’écran à prévoir : liste des Backend User Groups avant réorganisation.

Associez ensuite chaque groupe à une fonction précise.

La documentation TYPO3 propose notamment les préfixes suivants.

TYPO3 accepte naturellement n’importe quel titre de groupe : ces préfixes sont une convention d’organisation.

Pour un projet, choisissez une seule convention, courte ou longue, et appliquez-la uniformément.

Convention recommandée pour un projet TYPO3

La forme courte est particulièrement pratique lorsque plusieurs dizaines de groupes sont utilisés :

R_
PG_
DBM_
FM_
CM_
ACL_
FO_
L_

TYPO3 trie les groupes alphabétiquement. Les préfixes permettent donc de regrouper visuellement les groupes ayant une fonction similaire.

Éditez chaque Backend User Group et modifiez son Title.

Évitez les noms trop génériques comme :

Editors
Files
Website
News
Languages
Site access

Préférez des noms qui indiquent immédiatement la fonction du groupe :

R_content_editor
FM_site_principal
DBM_site_principal
ACL_news
L_fr_en
FO_read_write

Dans un environnement multisite, ajoutez le site lorsque le groupe lui est propre :

PG_site_a
DBM_site_a
FM_site_a

PG_site_b
DBM_site_b
FM_site_b

À l’inverse, ne répétez pas le nom du site lorsqu’un groupe est volontairement réutilisable :

ACL_news
ACL_content_elements
FO_read_write
L_fr_en

Cette distinction entre groupes propres à un site et groupes partagés est également utilisée dans l’exemple multisite présenté par la documentation TYPO3.

Résultat attendu : les groupes sont automatiquement regroupés visuellement par préfixe dans les listes et sélecteurs TYPO3.

Le nom d’un groupe devrait permettre de comprendre sa fonction rapidement, mais il ne peut pas toujours expliquer toutes ses particularités.

TYPO3 recommande d’utiliser le champ Description, disponible dans l’onglet Notes, pour documenter la portée ou la raison d’être du groupe.

Par exemple, pour :

ACL_news

vous pourriez utiliser une description comme :

Permet de consulter, créer et modifier les enregistrements
d'actualités nécessaires aux éditeurs de contenu.

Pour :

DBM_site_principal

utilisez par exemple :

Donne accès à l'arborescence du site principal à partir
de la page racine du site.

Une personne qui administre TYPO3 plusieurs mois plus tard devrait pouvoir comprendre la fonction du groupe sans analyser chaque permission individuellement.

Un groupe nommé :

Editors

contient souvent, sur les installations TYPO3 ayant évolué pendant plusieurs années :

• des modules;
• des DB Mounts;
• des File Mounts;
• des permissions de tables;
• des langues;
• des permissions de pages;
• des permissions provenant d’extensions.

Cette configuration fonctionne, mais devient difficile à maintenir.

Il est préférable de décomposer ce groupe en plusieurs unités fonctionnelles.

Par exemple :

PG_site_principal
DBM_site_principal
FM_site_principal
FO_read_write
L_fr_en
ACL_content
ACL_news

Puis de créer un groupe de rôle :

R_content_editor

qui hérite de ces groupes.

TYPO3 décrit justement les groupes techniques et ACL comme des composants pouvant être combinés pour former un Role Group.

Éditez votre Role Group, par exemple :

R_content_editor

Dans la configuration d’héritage des groupes, ajoutez les groupes nécessaires à ce rôle.

Exemple :

R_content_editor
    ↓
PG_site_principal
DBM_site_principal
FM_site_principal
FO_read_write
L_fr_en
ACL_content
ACL_news

Le groupe R_content_editor devient alors un assemblage de permissions.

Un autre rôle peut réutiliser certaines des mêmes briques :

R_news_editor
    ↓
PG_site_principal
DBM_actualites
FM_actualites
FO_read_write
L_fr_en
ACL_news

Vous évitez ainsi de reproduire manuellement les mêmes permissions dans plusieurs groupes.

TYPO3 recommande que les Role Groups obtiennent leurs permissions exclusivement par héritage et n’aient pas de permissions configurées directement.

Une fois votre structure réorganisée, les utilisateurs devraient idéalement recevoir un groupe représentant leur rôle, plutôt qu’une collection de groupes techniques.

Préférez :

Jean Tremblay
└── R_content_editor

à :

Jean Tremblay
├── PG_site_principal
├── DBM_site_principal
├── FM_site_principal
├── FO_read_write
├── L_fr_en
├── ACL_content
└── ACL_news

La documentation TYPO3 recommande que les petits groupes soient combinés en Role Groups et que ces groupes de rôles constituent le niveau supérieur assigné aux utilisateurs.

Cette structure simplifie considérablement les changements futurs.

Si tous les éditeurs doivent recevoir une nouvelle permission, il suffit par exemple d’ajouter :

ACL_new_feature

à R_content_editor, plutôt que de modifier chaque utilisateur.

Après avoir modifié la structure des groupes, vérifiez les droits réels des utilisateurs concernés.

Le module de gestion des utilisateurs backend permet notamment :

• d’afficher les permissions combinées d’un utilisateur;
• de comparer les permissions;
• de simuler un utilisateur backend.

Testez au minimum :

• l’arborescence de pages visible;
• les modules backend disponibles;
• la modification des pages;
• les types de contenu autorisés;
• les fichiers accessibles;
• les opérations possibles sur les fichiers;
• les langues accessibles;
• les fonctionnalités fournies par vos extensions.

Capture d’écran à prévoir : simulation d’un utilisateur après réorganisation.

Pour un site TYPO3 comprenant des éditeurs et des responsables d’actualités, une structure pourrait ressembler à ceci :

ROLE GROUPS
├── R_content_editor
└── R_news_editor

PAGE GROUPS
└── PG_site_principal

DATABASE MOUNTS
├── DBM_site_principal
└── DBM_actualites

FILE MOUNTS
├── FM_site_principal
└── FM_actualites

FILE OPERATIONS
└── FO_read_write

LANGUAGES
└── L_fr_en

ACCESS CONTROL
├── ACL_content
└── ACL_news

Puis :

R_content_editor
├── PG_site_principal
├── DBM_site_principal
├── FM_site_principal
├── FO_read_write
├── L_fr_en
└── ACL_content

et :

R_news_editor
├── PG_site_principal
├── DBM_actualites
├── FM_actualites
├── FO_read_write
├── L_fr_en
└── ACL_news

Cette architecture permet de modifier une permission technique sans devoir reconstruire tous les rôles qui en dépendent.

Après la réorganisation, la liste des Backend User Groups devrait être beaucoup plus lisible.

Par exemple :

ACL_content
ACL_news
ACL_news_extended

DBM_actualites
DBM_site_principal

FM_actualites
FM_site_principal

FO_read_write

L_fr_en

PG_site_principal

R_content_editor
R_news_editor

Un administrateur peut alors identifier immédiatement la fonction probable d’un groupe simplement en consultant son préfixe.

Les rôles utilisateurs deviennent également distincts des permissions techniques nécessaires à leur fonctionnement.

• TYPO3 recommande de distinguer System Groups, ACL Groups et Role Groups.
• Utilisez des préfixes comme R_, PG_, DBM_, FM_, CM_, ACL_, FO_ et L_.
• Un groupe devrait avoir une responsabilité claire et limitée.
• Les Role Groups devraient obtenir leurs permissions par héritage plutôt que contenir leurs propres permissions.
• Assignez idéalement les utilisateurs à des Role Groups plutôt qu’à une multitude de groupes techniques.