75 lines
3.1 KiB
Markdown
75 lines
3.1 KiB
Markdown
|
# Phase 1 — implémentation documentaire et planning interne
|
||
|
|
|
||
|
|
Date : 22 août 2026
|
||
|
|
Base de vérification : copie locale de la base MariaDB issue de la VM
|
||
|
|
Périmètre : fondations V1, sans moteur d'optimisation complet.
|
||
|
|
|
||
|
|
## Migration
|
||
|
|
|
||
|
|
`g1a2b3c4d5e6_phase1_documents_planning.py` (depuis
|
||
|
|
`9f4a1b2c3d5e`) ajoute :
|
||
|
|
|
||
|
|
- `document_type` indexé à `intervention_documents` et
|
||
|
|
`equipment_documents`, avec valeur historique `autre` ;
|
||
|
|
- provenance, identifiant externe, synchronisation, protection, statut de
|
||
|
|
résolution, période de validité, type d'événement et conflit à
|
||
|
|
`room_schedules` ;
|
||
|
|
- permission `documents.view` et ses attributions aux rôles métier existants.
|
||
|
|
|
||
|
|
La migration est idempotente sur les colonnes et préserve les lignes
|
||
|
|
existantes. Aucun fichier ni document métier n'est copié.
|
||
|
|
|
||
|
|
## Centre documentaire
|
||
|
|
|
||
|
|
Le service `app_new/documents/service.py` fournit des adaptateurs de lecture
|
||
|
|
pour `InterventionDocument`, `EquipmentDocument` et `ProductDocument`.
|
||
|
|
Chaque résultat expose sa source, son objet parent, son type, sa date, son
|
||
|
|
contexte, son téléchargement et sa localisation calculée. Les produits avec
|
||
|
|
plusieurs soldes affichent plusieurs emplacements.
|
||
|
|
|
||
|
|
Routes ajoutées :
|
||
|
|
|
||
|
|
- `/documents/` : recherche, filtres source/type/période, pagination ;
|
||
|
|
- `/documents/fds` : vue FDS des produits accessibles ;
|
||
|
|
- `/documents/download/<source>/<id>` : contrôle RBAC, racine de stockage,
|
||
|
|
existence du fichier et nom de téléchargement.
|
||
|
|
|
||
|
|
Le lien de navigation est conditionné à `documents.view`. Les permissions de
|
||
|
|
lecture du module source restent obligatoires ; aucune permission
|
||
|
|
`documents.manage` ou `documents.download` n'est créée.
|
||
|
|
|
||
|
|
## Planning interne des salles
|
||
|
|
|
||
|
|
`app_new/core/services/room_planning.py` est la vue résolue commune. Elle
|
||
|
|
ignore les créneaux désactivés/supplantés, permet à Pronote de supplanter un
|
||
|
|
manuel non protégé, conserve un manuel protégé et signale les conflits.
|
||
|
|
`sync_pronote_schedules()` reçoit uniquement des données normalisées et ne
|
||
|
|
contacte pas Pronote.
|
||
|
|
|
||
|
|
Routes ajoutées : `/planning/rooms` et `/planning/rooms/new`, avec protection
|
||
|
|
manuelle exprimée en français. Les détails de salle et l'affichage Pronote
|
||
|
|
réutilisent la résolution interne.
|
||
|
|
|
||
|
|
## Préventif et disponibilité
|
||
|
|
|
||
|
|
`PlanningService` délègue désormais la disponibilité de salle au service
|
||
|
|
interne. La durée existante d'une `ScheduledTask` est utilisée pour le contrôle
|
||
|
|
de créneau ; aucun solveur, replanificateur ou moteur multi-techniciens n'est
|
||
|
|
inclus dans cette phase.
|
||
|
|
|
||
|
|
## Tests et données
|
||
|
|
|
||
|
|
- `tests/integration/test_phase1_documents_planning.py` : 3 scénarios ciblés ;
|
||
|
|
- suites P1/formulaires/stock/interventions : 20 tests passants ;
|
||
|
|
- compte local `TEST_UI_PHASE1_ADMIN` conservé pour inspection manuelle ;
|
||
|
|
- aucune donnée `TEST_UI_*` supprimée et `alban` inchangé.
|
||
|
|
|
||
|
|
## Limites restantes
|
||
|
|
|
||
|
|
- synchronisation Pronote réelle et résolution de rapprochements ambigus à
|
||
|
|
brancher sur l'intégration existante ;
|
||
|
|
- optimisation journalière, replanification, tâches multi-techniciens et
|
||
|
|
classeur FDS hors périmètre ;
|
||
|
|
- revalidation VM distante et campagne complète responsive/accessibilité à
|
||
|
|
effectuer séparément.
|