57 lines
3.5 KiB
SQL
57 lines
3.5 KiB
SQL
-- ============================================================================
|
|
-- PTA V7.27 — Le Service Enfance gère les jetons des agents et des responsables
|
|
-- ============================================================================
|
|
-- La distribution des accès était entièrement portée par la DSI (V7.11). Dans
|
|
-- les faits, c'est le Service Enfance qui sait qu'un agent est arrivé, qu'un
|
|
-- responsable a perdu son jeton ou qu'un remplaçant part : passer par la DSI
|
|
-- pour chaque mouvement de terrain ajoutait un délai sans ajouter de contrôle.
|
|
--
|
|
-- CETTE DÉLÉGATION EST STRICTEMENT BORNÉE À DEUX RÔLES : AGENT et
|
|
-- RESPONSABLE_STRUCTURE. Les comptes SERVICE_ENFANCE et DSI restent à la seule
|
|
-- main de la DSI, et ce n'est pas une commodité d'affichage :
|
|
-- * un compte SERVICE_ENFANCE créé par le Service Enfance serait une
|
|
-- auto-promotion — le rôle se distribuerait lui-même sans contrôle externe ;
|
|
-- * un compte DSI créé par le Service Enfance lui ouvrirait le journal
|
|
-- d'activité, c'est-à-dire la trace de ses propres actions.
|
|
-- La borne est doublée en PHP (AccessAccountController::ROLES_DELEGUES), parce
|
|
-- qu'une frontière de privilège ne doit pas dépendre d'une seule ligne de
|
|
-- données : une ligne mal saisie ici ne doit pas pouvoir ouvrir la création de
|
|
-- comptes privilégiés.
|
|
--
|
|
-- POURQUOI « v7_9h » : les migrations sont jouées dans l'ORDRE ALPHABÉTIQUE
|
|
-- (docker/db/apply-migrations.sh). Le préfixe suit la dernière migration en date
|
|
-- (v7_9g), pas le numéro de version fonctionnelle. Voir CLAUDE.md.
|
|
--
|
|
-- Prérequis : migration_v7_8_securite_acces.sql (tables acces_role_*) et
|
|
-- migration_v7_9e_dsi_comptes_journal.sql (compte_acces, rôle DSI).
|
|
-- Idempotente : rejouable sans effet de bord.
|
|
-- ============================================================================
|
|
|
|
-- ----------------------------------------------------------------------------
|
|
-- AUCUNE PAGE NOUVELLE
|
|
-- ----------------------------------------------------------------------------
|
|
-- La gestion des jetons prend place dans l'onglet « Administration », déjà
|
|
-- ouvert au Service Enfance depuis la V7.8 : c'est là que vivent les réglages
|
|
-- qu'on pose une fois, à côté des horaires de couverture. Il n'y a donc rien à
|
|
-- insérer dans acces_role_page — et rien qui puisse ouvrir cet écran à un autre
|
|
-- rôle par mégarde.
|
|
--
|
|
-- ----------------------------------------------------------------------------
|
|
-- LA PERMISSION
|
|
-- ----------------------------------------------------------------------------
|
|
-- `can_manage_field_access` : distribuer les jetons DE TERRAIN (agents et
|
|
-- responsables de lieu). À ne pas confondre avec `can_manage_access`, qui reste
|
|
-- la permission de la DSI et couvre TOUS les comptes, y compris privilégiés.
|
|
--
|
|
-- Les refus sont écrits explicitement plutôt que laissés absents : une ligne à
|
|
-- FALSE documente une décision, une ligne absente laisse croire à un oubli (une
|
|
-- permission inconnue vaut de toute façon « refusé »).
|
|
INSERT INTO acces_role_permission (role, permission, autorise) VALUES
|
|
('SERVICE_ENFANCE', 'can_manage_field_access', TRUE),
|
|
-- La DSI n'en a pas besoin : can_manage_access lui ouvre déjà tous les
|
|
-- comptes. Lui donner celle-ci n'ajouterait rien et brouillerait la lecture.
|
|
('DSI', 'can_manage_field_access', FALSE),
|
|
('AGENT', 'can_manage_field_access', FALSE),
|
|
('RESPONSABLE_STRUCTURE', 'can_manage_field_access', FALSE)
|
|
ON DUPLICATE KEY UPDATE autorise = VALUES(autorise);
|