Files
pta/README_V7_10.md
PTA 4201894e28 V7.10 — Tableau de bord, guide, semaine type et enveloppe de formation
Reprise dans le répertoire de production du travail mené dans le worktree
ux-service-enfance :

- tableau de bord Service Enfance (dashboard.php) et navigation regroupée ;
- guide d'utilisation (faq.php) accessible depuis toute la navigation ;
- éditeur de semaine type mis en avant sur l'écran de saisie ;
- droit à l'enveloppe de formation par agent, en remplacement de la case
  « formation déjà prévue dans la répartition annuelle » ;
- correctif de « [object Object] » sur les cartes de quota du PTA ;
- motif de travail par défaut à la saisie, heures travaillées complètes
  dans les PDF.

Le docker-compose.yml de production est conservé : celui du worktree décrit
une pile de test (conteneurs et volume suffixés « test », ports 9080/9081),
qui aurait fait redémarrer l'application sur un volume MariaDB vide.

Les migrations database/migration_v7_9*.sql sont obligatoires ; le service
db-migrate les applique au déploiement.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 16:53:04 +02:00

4.9 KiB

PTA V7.10 — Éditeur de semaine type et méthode de saisie explicite

Le problème traité

L'écran de saisie ne proposait qu'un seul chemin : choisir un lieu, un agent, une semaine, puis remplir les cinq jours. Répéter ce travail semaine après semaine pour un même agent était la norme.

Les semaines types existaient déjà, mais elles étaient subordonnées à ce chemin :

  • on ne pouvait créer un modèle qu'en enregistrant une semaine déjà planifiée — impossible de composer directement une semaine de référence ;
  • les trois boutons (« Enregistrer comme semaine type », « Importer une semaine type », « Appliquer sur une période ») étaient rangés dans l'en-tête de l'étape 3, à côté du bouton PDF, donc trouvés par hasard ;
  • rien n'indiquait que dupliquer un modèle sur une période était la voie la plus rapide.

Ce qui change

1. La méthode de saisie devient un choix explicite

Après la sélection de l'agent, une étape « Choisir la méthode de saisie » propose deux voies :

  • Semaine type — marquée « Le plus rapide », ouverte par défaut : composer une semaine de référence, puis la dupliquer sur une période entière ;
  • Semaine précise — saisir ou corriger une seule semaine, jour par jour.

Le second mode est l'écran d'avant, inchangé : mêmes champs, mêmes contrôles, mêmes boutons.

Un lien profond qui désigne une semaine (file de validation, tableau de bord, vue annuelle, bouton « Corriger cette semaine ») ouvre directement le mode Semaine précise : la priorité donnée à la semaine type ne doit jamais détourner quelqu'un qui vient corriger un planning identifié.

Les rôles sans droit aux semaines types — Responsable de structure — ne voient aucun sélecteur : la page reste exactement celle qu'ils connaissent, et la numérotation des étapes se resserre de 1-2-3.

2. Un vrai éditeur de semaine type

Le mode « Semaine type » affiche les cinq jours ouvrés côte à côte. Pour chaque jour :

  • ajouter autant de plages que nécessaire, chacune avec son motif, ses horaires et son lieu — une semaine type peut donc couvrir plusieurs lieux d'affectation, comme le permet le modèle de données ;
  • un total par jour, et le total de la semaine avec la part réellement décomptée du quota ;
  • « Copier vers… » : recopier un jour sur un autre, ou sur tous les autres d'un coup — la façon la plus courante de construire une semaine régulière.

La barre d'outils permet d'ouvrir une semaine type existante de l'agent, de la renommer, de l'enregistrer ou de la supprimer. Rien n'est planifié à ce stade : une semaine type est une description, pas un planning. Deux actions la transforment en plannings réels :

  • Dupliquer sur une période… — la modale existante, avec ses filtres scolaire/vacances, son mode compléter/remplacer et sa prévisualisation ;
  • Appliquer à la semaine sélectionnée… — la modale d'import existante.

Ces deux boutons restent inactifs tant que le modèle n'a pas été enregistré : on ne duplique jamais un brouillon d'écran, seulement ce qui est réellement en base.

3. Les contrôles ne bougent pas

Les plages composées à l'écran sont intégralement revalidées par le serveur :

  • jours limités au lundi-vendredi ;
  • horaires par tranches de 15 minutes, fin postérieure au début ;
  • pas de chevauchement entre deux plages du même jour, même sur deux lieux différents — un agent n'est jamais à deux endroits à la fois ;
  • lieu actif, motif actif, et « Formation » refusé pour un agent sans droit à l'enveloppe de formation, exactement comme à la saisie semaine par semaine.

L'écran effectue les mêmes contrôles avant d'envoyer, uniquement pour éviter un aller-retour inutile.

Fichiers

Ajouté Rôle
assets/js/week-template-editor.js module PTA.modules.weekTemplateEditor
api/week_template.php contenu détaillé d'une semaine type (GET)
api/save_week_template_entries.php enregistrement depuis l'éditeur (POST)
Modifié Raison
app/Models/WeekTemplateModel.php saveFromEntries(), validation des plages, persistance factorisée avec saveFromWeek()
app/Controllers/WeekTemplateController.php show() et storeEntries()
app/Views/partials/planning_editor.php sélecteur de méthode et panneau de l'éditeur
app/Controllers/PageController.php chargement du module, sous-titre selon le droit
assets/js/week-templates.js openApplyModal() / openPeriodModal() exposés, avec modèle présélectionné
assets/js/page-bootstrap.js un lien profond vers une semaine ouvre le mode « Semaine précise »
assets/style.css styles du sélecteur de méthode et de l'éditeur

Aucune migration SQL : modele_semaine_agent et modele_semaine_creneau portaient déjà exactement ce que l'éditeur produit (jour, lieu, motif, horaires).