Supprimer la saisie de date d'arrêté

johanricher commented 2 weeks ago

Description

Suite au problème identifié et décrit sur #701, une réunion a eu lieu aujourd'hui pour se mettre d'accord sur l'implémentation de la solution. Celle-ci reprend la proposition discutée il y a quelques mois : ne plus demander la saisie des dates de début et fin d'un arrêté lors de la création d'un arrêté dans l'UI de DiaLog.

Les dates de début et fin d'un arrêté continueront cependant à être affichées quand le besoin se présente (par exemple valeurs de "période" sur la page qui liste les arrêtés) et que cela n'entraine pas de confusion (voir discussion sur #843 pour un exemple). Les valeurs en question seront inférées à partir des dates de début/fin des restrictions ("mesures") qui composent l'arrêté (début d'un arrêté = date la plus tôt de début d'une restriction ; fin d'un arrêté = date la plus tard de fin d'une restriction).

Dans le cadre de cette évolution des adaptations du formulaire sont nécessaire pour simplifier la saisie.

Implémentation

Sur la première page du formulaire de création d'un arrêté ("Informations générales") : supprimer la saisie des dates sur l'arrêté
Enregistrer en base les dates de début et fin d'un arrêté en les inférant à partir de celles des restrictions
Sur la deuxième page du formulaire de de création d'un arrêté : la saisie des dates de début et de fin d'une restriction est toujours affichée
Remplacer "plage", "jours et horaires" par "Périodes d'application" + autres reformulation (voir maquette)

Design

Maquette

florimondmanca commented 10 hours ago

On a un tout petit sujet supplémentaire posé par ce ticket :

Actuellement pour savoir si un arrêté est "permanent" ou "temporaire", on regarde si une date de fin a été définie au niveau de l'arrêté

En fonction de ça on affiche ou pas les champs de date de fin dans le formulaire des périodes pour les mesures

Ici on veut inverser la logique, et faire en sorte que les dates de l'arrêté "remontent" des périodes des mesures

Par conséquent, il faut un moyen plus explicite de configurer le fait qu'un arrêté soit permanent ou temporaire, non ?

cc @aureliebaton

On pourrait dire : si aucune période n'a de date de fin, alors c'est du permanent, sinon c'est du temporaire... Mais est-ce que c'est satisfaisant en termes d'UX ?

aureliebaton commented 10 hours ago

C'est une bonne question en effet. Le plus explicite serait peut-être d'ajouter une liste dans le premier formulaire pour sélectionner l'un ou l'autre (temporaire ou permanent). Par exemple à la place de la liste "Nature de l'arrêté" dont on ne se sert pas.

florimondmanca commented 9 hours ago

@mmarchois Est-ce que tu aurais un avis technique sur le calcul et le stockage / synchronisation des dates globales ? (On peut réutiliser la terminologie datex de la overallPeriod)

Au niveau du calcul ces dates sont un MIN(period.startDate) et MAX(period.endDate), donc avec double jointure (regulationOrder -> measure -> period)

J'ai envisagé ces options...

Créer une VIEW en relation one-to-one avec RegulationOrder
- La VIEW est exécutée à chaque fois qu'on y accède, potentiellement de façon "incontrôlée" (requêtes inutiles, cache la complexité, source de problèmes de perf ?)
Créer une MATERIALIZED VIEW pour éviter les recalculs
- Mais il faut gérer son rafraîchissement en appelant REFRESH MATERIALIZED VIEW, donc ça ne semble pas appropriées (les vues matérialisées c'est plutôt un cas d'usage d'analytics j'ai l'impression)
Faire "manuellement" et explicitement le calcul au niveau des repository chaque fois qu'on a besoin de ces dates globales
- => :heart: C'est l'option vers laquelle je tends pour l'instant... Car c'est la plus explicite donc la moins sujette à introduire des bugs
- On pourrait combiner avec une VIEW pour "factoriser" la requête, mais on peut peut-être être + efficace au cas par cas (parfois on fait déjà les jointures sur measure et period de toute façon)
Créer des champs overallStartDate, overallEndDate (renommage des champs actuels) mis à jour par des TRIGGER lors d'un INSERT / UPDATE
- Les triggers rendent le code moins maintenable car il faut savoir qu'ils existent
- Il faudrait s'assurer que le trigger se déclenche quand une période est modifiée sur une des mesures de l'arrêté : la condition de déclenchement peut-être prendre en compte des jointures ? Ça a l'air compliqué
Créer ces champs et les peupler manuellement dans le code applicatif
- Lors d'un update() sur une Period, remonter l'info pour aller modifier le RegulationOrder
- Soit en synchrone (balader une référence à l'arrêté jusque dans le code des périodes), soit par un "signal" / événement
- Semble un peu compliqué aussi, mais moins pire que l'option 4)

johanricher commented 6 hours ago

Ici on veut inverser la logique, et faire en sorte que les dates de l'arrêté "remontent" des périodes des mesures

Par conséquent, il faut un moyen plus explicite de configurer le fait qu'un arrêté soit permanent ou temporaire, non ?

Si la définition d'arrêté permanent est "un arrêté contenant au moins une restriction sans date de fin", alors on n'a pas besoin de demander au préalable à la personne de choisir "permanent" ou "temporaire", c'est une information dont la saisie est redondante.

Je ne vois pas de cas où le fait que la saisie ne soit pas explicite poserait un problème.

L'information devrait néanmoins restée affichée (comme pour les valeurs de périodes de l'arrêté) : inférée et non pas demandée.

A l'inverse, si on veut une UX où la personne doit choisir explicitement entre "permanent" et "temporaire", il risque d'y avoir une confusion.

Par exemple : je choisis "arrêté permanent" sans comprendre exactement ce que ça veut dire, et ensuite le formulaire rend impossible de choisir une date de fin pour la restriction, et je ne comprends pas pourquoi.

Autre exemple : je choisis "arrêté permanent" mais je veux définir 2 restrictions dont seulement une n'a pas de date de fin.

MTES-MCT / dialog