update

database/migration_v7_9h_jetons_service_enfance.sql

@@ -0,0 +1,56 @@
+-- ============================================================================
+-- 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);