# 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. 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. ## 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. # 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.