Repository navigation
Conversation
stakovicz
reviewed
Oct 11, 2026
Korbeil
force-pushed
the
afup-ajouter-un-check-isgranted
branch
from
October 12, 2026 14:35
a9c5ba0 to
49df2cf
Compare
Korbeil
marked this pull request as ready for review
October 12, 2026 15:00
Korbeil
force-pushed
the
afup-ajouter-un-check-isgranted
branch
from
October 12, 2026 15:16
49df2cf to
ee8c035
Compare
stakovicz
approved these changes
Oct 13, 2026
Korbeil
force-pushed
the
afup-ajouter-un-check-isgranted
branch
from
October 13, 2026 14:45
ee8c035 to
239742e
Compare
Korbeil
force-pushed
the
afup-ajouter-un-check-isgranted
branch
from
October 25, 2026 13:00
239742e to
3d91038
Compare
…s accès admin - les droits du back-office sont portés par les rôles ROLE_<MODULE>_READER/_WRITER : les colonnes niveau et niveau_modules sont supprimées (migration de conversion) - formulaire : matrice Aucun / Lecteur / Gestionnaire par module et cases à cocher pour les rôles hors matrice (super administrateur, gestionnaire de personne morale) - liste des administrateurs et menu recalés sur les nouveaux rôles
Korbeil
force-pushed
the
afup-ajouter-un-check-isgranted
branch
from
October 27, 2026 13:22
3d91038 to
a32b928
Compare
stakovicz
reviewed
Oct 27, 2026
…au super admin, menu Salles - La migration ne convertit plus niveau / niveau_modules : seuls ROLE_MEMBER_* et ROLE_COMPANY_MANAGER sont conservés, la personne physique 3225 devient l'unique super admin (migration ignorée si elle n'existe pas). - Seul un super admin peut modifier le mot de passe d'une personne physique. - Le menu Salles requiert ROLE_EVENT_WRITER, comme son contrôleur.
Member
Author
|
merci pour la review @stakovicz ça wype tous les accès comme on s'était dis et ça file les droits à Nathan puis on réassignera depuis le BO |
Korbeil
marked this pull request as draft
October 27, 2026 17:25
Korbeil
marked this pull request as ready for review
October 28, 2026 09:30
stakovicz
reviewed
Oct 29, 2026
Korbeil
marked this pull request as draft
October 29, 2026 14:20
… super admin, droits effectifs des administrateurs, règle PHPStan ROLE_ADMIN
Korbeil
marked this pull request as ready for review
October 30, 2026 13:55
stakovicz
approved these changes
Nov 1, 2026
Contributor
|
Bravo pour cette PR ! Prêt pour le bigbang ! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Refonte complète du contrôle d'accès au back-office
/adminsuivant l'audit de sécurité : chaque module dispose désormais d'un couple de rôles*READER/*WRITER,ROLE_ADMINdevient un simple marqueur d'accès à la console etROLE_SUPER_ADMINn'est plus attribué automatiquement. Toutes les routes admin sont maintenant fermées explicitement (deux barrières), avec un filet default-deny. Changement cassant : les comptes avecLEVEL_ADMINne récupèrent queROLE_ADMIN(l'impersonation nécessite désormaisROLE_SUPER_ADMINattribué explicitement).Changes
#[IsGranted]sur tous les controllers admin (lecture sur les listes/exports, écriture sur les add/edit/delete), avec matrice testée par un data provider PHPUnit sur chaque route.access_control: règles explicites par module (READ sur les consultations, WRITE sur les mutations), page « Divers » réservée àROLE_SUPER_ADMIN, default-deny sur le reste de/admin.ROLE_ADMIN(marqueur console vide),ROLE_SUPER_ADMIN= tous les READ + impersonation ; rôles legacy (ROLE_VEILLE,ROLE_SITE,ROLE_FORUM,ROLE_APERO,ROLE_ANTENNE,ROLE_ANNUAIRE) forcés en pont vers les nouveaux rôles.How to test
/admin(403 sur/admin/logs,/admin/speaker, …).ROLE_SUPER_ADMIN: vérifier l'accès complet (listes en lecture + actions d'écriture) et les pagesDivers; avec un compte limité à un rôle module (ex.ROLE_VEILLE_READER) : console visible mais uniquement les pages de son module.vendor/bin/phpunit tests/integration/AppBundle/Security/AdminAccessControlTest.php: chaque route/admindoit passer la matrice d'accès au furet des rôles.Interface « Paramètres » des personnes physiques (refonte)
Les formulaires personnes physiques (ajout / modification) reflètent la matrice READ/WRITE par module :
ROLE_ADMIN(décochée par défaut)ROLE_*_READER/ROLE_*_WRITERniveau_modulespasse de 5 à 9 caractères (0 = --, 1 = Lecture seule, 2 = Gestionnaire), les niveaux existants sont conservés par migrationROLE_ADMINou un rôle fonctionnel (READ ⩾) est porté, y compris en lecture seulePour tester : Admin → Personnes physiques → Ajouter, vérifier la case et les 9 selects ; enregistrer un utilisateur « Lecture seule » sur un module (accès console sans modification) ; vérifier les colonnes par module dans « Administrateurs du site ».
Screenshot