-- ============================================================================
-- 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);