# 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

```text
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é :

```text
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`.