PTA V6 — application PHP MVC multipage

PTA n’est plus une SPA. Chaque fonction principale correspond à une page PHP distincte :

• planning.php : saisie, brouillon, validation et semaines types ;
• pending.php : plannings en attente de validation ;
• coverage.php : contrôle des créneaux sans agent ;
• structures.php : planning hebdomadaire par lieu ;
• agents.php : planning mensuel et bilan par agent ;
• vacations.php : aperçu et enregistrement des vacances scolaires ;
• administration.php : lieux, agents et règles de couverture.

index.php redirige vers le choix de rôle lors de la première visite, puis vers la page d’accueil autorisée pour le profil sélectionné.

Architecture

page PHP
  → PageController
    → Models / Services
      → View dédiée

View
  → API JSON uniquement pour les actions asynchrones utiles

Les contrôleurs métier, modèles, services PDF et endpoints API de la V5.20 sont conservés. La différence principale porte sur l’interface : plus de routeur JavaScript, plus de vues cachées et plus de chargement de tous les modules sur une seule page.

JavaScript chargé par page

• Saisie : planning-editor.js et week-templates.js ;
• À valider : pending-validation.js ;
• Couverture : coverage.js ;
• Par lieu : structure-overview.js ;
• Par agent : agent-overview.js ;
• Vacances : vacation-calendar.js ;
• Administration : administration.js et la partie configuration de coverage.js.

assets/js/page-bootstrap.js initialise uniquement les modules déclarés par la page et applique les filtres transmis dans l’URL.

Liens directs

Une page de contrôle peut ouvrir directement le planning concerné :

planning.php?structure_id=2&agent_id=7&week=2026-W31&focus=validation

Installation

1. Configurer config.php.
2. Utiliser le schéma SQL correspondant à la V5.20.
3. Placer le dossier sur le serveur PHP.
4. Ouvrir index.php ou planning.php.

Aucune migration SQL supplémentaire n’est nécessaire pour passer de la V5.20 à la V6.

Version 7

Voir README_V7.md pour le nouveau socle PTA annuel, les équipes des mercredis/vacances et les contrôles métier associés.

V7.2 — Vue annuelle

La page annual.php reproduit l’esprit du tableau annuel historique : douze mois côte à côte, codes AP/PP/AE/PE, couleurs métier, vacances scolaires et accès direct à la semaine à corriger. Voir README_V7_2.md.

V7.8 — Sécurité et droits en base

Les correctifs de sécurité et le déplacement de la matrice des droits dans des vues SQL sont décrits dans README_V7_8.md. La migration database/migration_v7_8_securite_acces.sql est obligatoire ; elle est appliquée automatiquement au déploiement par le service db-migrate du docker-compose.

V7.4 — Rôles et droits d’accès

La première arrivée ouvre role.php. Les droits Agent, Responsable de structure et Service Enfance sont vérifiés dans les pages et les contrôleurs API. Voir README_V7_4.md.

V7.11 — Connexion par jeton, espace DSI et journal d’activité

role.php n’est plus un sélecteur de rôle : chaque utilisateur se connecte avec un jeton personnel distribué par la DSI, dont la base ne conserve qu’une empreinte SHA-256. Un quatrième rôle DSI ouvre dsi.php : gestion des comptes d’accès (dont les administrateurs Service Enfance) et lecture du journal d’activité, qui trace les connexions, les écritures en base et les refus d’accès. La migration database/migration_v7_9e_dsi_comptes_journal.sql est obligatoire ; elle crée aussi le compte DSI d’installation dont le jeton, public, est à régénérer immédiatement. Voir README_V7_11.md.

V7.12 — Mot de passe des comptes privilégiés

Les comptes Service Enfance et DSI ajoutent un second facteur à leur jeton : un mot de passe choisi par leur titulaire à sa première connexion, que la DSI ne peut qu’effacer, jamais lire. Les agents et les responsables de lieu restent à un seul facteur. Migration database/migration_v7_9f_mot_de_passe_admin.sql. Voir README_V7_12.md.

V7.13 — Nom et prénom modifiables

La fiche agent laisse désormais corriger le nom et le prénom, à côté des autres champs déjà modifiables. Le matricule et la quotité de travail restent immuables. Un renommage est journalisé avec l’identité précédente. Aucune migration. Voir README_V7_13.md.

V7.14 — Groupe de navigation « Management »

Les agents et les lieux d’affectation quittent l’onglet « Administration » pour deux onglets distincts, réunis dans un groupe « Management » de la barre de navigation, au même titre que « Piloter » ou « Planifier ». « Administration » ne conserve que les horaires de couverture. Migration database/migration_v7_9g_management.sql (droits d’accès aux deux pages). Voir README_V7_14.md.

V7.15 — Affectations bornées par le contrat

Un agent ne peut plus être planifié avant sa date de début de contrat ni après sa date de fin, quel que soit le chemin d’écriture (saisie, déplacement, copie de semaine, semaine type). La validation signale les affectations devenues hors contrat, et raccourcir un contrat sous des affectations existantes est refusé. Aucune migration. Voir README_V7_15.md.