2026-08-23 15:26:53 +02:00
|
|
|
|
# Workflow maintenance external — proposition Phase 2.1
|
|
|
|
|
|
|
|
|
|
|
|
## État réel actuel
|
|
|
|
|
|
|
|
|
|
|
|
`LotTask` possède déjà `contrat`, `company_id`, `contract_id`,
|
|
|
|
|
|
`gestionnaire`, `periodicite` et `jours_entre_interventions`. `ScheduledTask`
|
|
|
|
|
|
possède également l’entreprise, le contrat, l’équipement, la salle,
|
|
|
|
|
|
l’affectation et les dates prévues/réelles. `ContractVisit` représente une
|
|
|
|
|
|
visite de contrat avec une date et un statut.
|
|
|
|
|
|
|
2026-08-23 16:02:47 +02:00
|
|
|
|
Cette base permet d'associer une tâche à une entreprise, mais ne distingue pas
|
|
|
|
|
|
encore proprement : date d'échéance, rendez-vous avec heure, passage libre,
|
|
|
|
|
|
arrivée réelle, non-venue et temps d'accompagnement du technicien.
|
|
|
|
|
|
|
|
|
|
|
|
## Implémentation Phase 2.1b
|
|
|
|
|
|
|
|
|
|
|
|
La migration `i4d5e6f7a8b9` et la page **Passages & contrôles** couvrent les
|
|
|
|
|
|
modes « Sur rendez-vous », « Date connue, heure inconnue » et « Passage libre »,
|
|
|
|
|
|
ainsi que la date réelle, l'arrivée, la non-venue et l'accompagnement
|
|
|
|
|
|
ponctuel/complet. Un rendez-vous avec heures devient une contrainte fixe de
|
|
|
|
|
|
`DayPlanner`; les autres modes sont des informations non bloquantes jusqu'à
|
|
|
|
|
|
l'arrivée de l'entreprise.
|
2026-08-23 15:26:53 +02:00
|
|
|
|
|
|
|
|
|
|
## Parcours métier proposé
|
|
|
|
|
|
|
|
|
|
|
|
1. Dans la fiche du lot, choisir l’exécutant : technicien du collège,
|
|
|
|
|
|
entreprise, Département ou mixte.
|
|
|
|
|
|
2. Si nécessaire, choisir l’entreprise et le contrat.
|
|
|
|
|
|
3. Définir le périmètre : tous les équipements actifs du lot/catégorie, ou une
|
|
|
|
|
|
sélection manuelle filtrée par bâtiment, zone et salle.
|
|
|
|
|
|
4. Définir la périodicité et la prochaine échéance séparément.
|
|
|
|
|
|
5. Choisir le mode de passage : rendez-vous, date sans heure ou passage libre.
|
|
|
|
|
|
6. Pour un rendez-vous, saisir date, heure/durée, notes et accompagnement.
|
|
|
|
|
|
7. À l’arrivée, enregistrer le passage réel ; une non-venue laisse la tâche à
|
|
|
|
|
|
réaliser et permet de proposer un nouveau rendez-vous.
|
|
|
|
|
|
|
|
|
|
|
|
## États métier proposés
|
|
|
|
|
|
|
|
|
|
|
|
`À planifier`, `Rendez-vous fixé`, `Passage libre`, `Arrivée`, `En cours`,
|
|
|
|
|
|
`Réalisé`, `Reporté`, `Non venue`, `Annulé`.
|
|
|
|
|
|
|
|
|
|
|
|
Le rendez-vous et le passage réel sont distincts. La prochaine échéance ne doit
|
|
|
|
|
|
être recalculée qu’après une vérification réellement enregistrée, selon les
|
|
|
|
|
|
règles du contrat. Par défaut, la proposition est : date réelle + périodicité.
|
|
|
|
|
|
|
|
|
|
|
|
## Temps d’entreprise et temps technicien
|
|
|
|
|
|
|
|
|
|
|
|
La durée de présence de l’entreprise n’est pas automatiquement la durée
|
|
|
|
|
|
bloquée dans `DayPlanner`. Une tâche doit distinguer :
|
|
|
|
|
|
|
|
|
|
|
|
- présence totale de l’entreprise ;
|
|
|
|
|
|
- accompagnement ponctuel du technicien ;
|
|
|
|
|
|
- accompagnement complet du technicien.
|
|
|
|
|
|
|
|
|
|
|
|
Seul l’accompagnement prévu bloque l’agenda du technicien. Un passage libre
|
|
|
|
|
|
reste une information/alerte et ne réserve aucun créneau arbitraire.
|
|
|
|
|
|
|
|
|
|
|
|
## Périmètre des équipements
|
|
|
|
|
|
|
|
|
|
|
|
Deux modes sont à prévoir :
|
|
|
|
|
|
|
|
|
|
|
|
- **dynamique** : tous les équipements actifs répondant au lot/catégorie et
|
|
|
|
|
|
aux filtres de localisation ;
|
|
|
|
|
|
- **manuel** : sélection explicite d’équipements.
|
|
|
|
|
|
|
|
|
|
|
|
Le mode dynamique simplifie la maintenance d’un parc qui évolue ; le mode
|
|
|
|
|
|
manuel convient à un contrat limité à quelques appareils. L’interface doit
|
|
|
|
|
|
afficher le nombre d’équipements concernés et permettre de revoir la sélection.
|
|
|
|
|
|
|
|
|
|
|
|
## Espaces verts
|
|
|
|
|
|
|
|
|
|
|
|
Les durées de tonte, bordures, taille et évacuation sont des durées propres à
|
|
|
|
|
|
une zone. Elles ne doivent pas être portées par une règle générique de lot.
|
|
|
|
|
|
Une extension dédiée de périmètre/zone est à concevoir après validation du
|
|
|
|
|
|
modèle de localisation existant.
|
|
|
|
|
|
|
|
|
|
|
|
## RBAC et sécurité
|
|
|
|
|
|
|
|
|
|
|
|
La consultation suit les permissions du lot, de l’entreprise et du planning.
|
|
|
|
|
|
La modification d’un contrat ou d’un rendez-vous doit être autorisée par la
|
|
|
|
|
|
permission métier correspondante. Les liens vers les équipements restent
|
|
|
|
|
|
protégés par les permissions patrimoine.
|
|
|
|
|
|
|
|
|
|
|
|
## Migration à étudier avant développement
|
|
|
|
|
|
|
|
|
|
|
|
Avant toute migration, comparer une extension de `LotTask`/`ContractVisit` avec
|
|
|
|
|
|
un modèle de passage séparé. Les champs éventuels seraient notamment : mode
|
|
|
|
|
|
d’exécutant, mode de passage, fenêtre, heure, durée d’accompagnement, statut,
|
|
|
|
|
|
date réelle et périmètre dynamique. Aucune table ni migration n’est créée dans
|
|
|
|
|
|
cette étude.
|
2026-08-23 15:41:43 +02:00
|
|
|
|
# Mise en œuvre Phase 2.1b
|
|
|
|
|
|
|
|
|
|
|
|
Les tâches de lot disposent maintenant d'un exécutant explicite (interne,
|
|
|
|
|
|
entreprise extérieure, Département, mixte ou à définir), d'une entreprise et
|
|
|
|
|
|
d'un contrat facultatifs, ainsi que d'un périmètre dynamique ou manuel.
|
|
|
|
|
|
Le rendez-vous, la fenêtre de passage, la non-venue et l'accompagnement
|
|
|
|
|
|
restent à implémenter autour de `ContractVisit` dans une migration dédiée ;
|
|
|
|
|
|
aucune date/heure fictive n'est donc créée dans cette passe.
|
