Problèmes liés aux dates de début et fin d'un arrêté #701
Comments
|
Afin d'estimer la criticité de ces problèmes et donc la priorisation d'une implémentation qui viserait à les corriger, je propose qu'on note en commentaires les problèmes rencontrés du point de vue utilisateur : un problème réellement bloquant justifierait une priorisation. En dehors de #697, le problème que je constate à l'heure actuel est plutôt UX et pas bloquant : une personne qui crée un arrêté en oubliant de mettre une date de fin au niveau de l'arrêté (étape 1), ne pourra pas mettre de date de fin au niveau de la ou les mesures composant l'arrêté. Pour corriger son erreur, la personne devra reprendre à zéro le parcours de création d'un arrêté (en mettant cette fois une date de fin). |
|
Vu à la MEL ce jour suite à la démo DiaLog
|
|
A quel besoin répond le fait d'avoir des dates au niveau de l'arrêté ? La finalité de DiaLog étant de diffuser dans les GPS uniquement des restrictions de circulations / "mesures" (pas des "arrêtés") et avec une date de fin (ce qui est permanent étant un changements de voirie, donc devrait être diffusé par exemple dans Google Maps et/ou OpenStreetMap). L'export DOCX pour le cas d'usage "papier" de DiaLog n'a pas non plus besoin de ça. Un arrêté n'a pas besoin de dates de début/fin pour être publié, si les mesures portent cette info. |
|
Sur le ticket #696 tu as fait le commentaire suivant :
De ce que je comprends de la discussion sur ce ticket, c'est un problème car la temporalité d'une mesure ne peut en aucun cas être inférée automatiquement à partir de celle de l'arrêté comme c'est le cas actuellement. Cela me semble être un argument supplémentaire pour supprimer toute notion de temporalité attachée à un arrêté, pour éviter des erreurs et confusions et en particulier dans nos exports (Datex, CIFS). |
Oui. DATEX II permet aussi de définir une validité globale, mais elle est optionnelle, on pourrait donc s'en passer complètement. Je pense que les dates de validité globales ont un usage plutôt côté coordination entre la collectivité et les sociétés de travaux (par ex). Un arrêté temporaire est par exemple donné pour 1 mois et l'entreprise de travaux est sensée s'organiser pour faire effectivement les travaux dans ce laps de temps. |
|
Lors de l'exploration sur la vue carto #659 concernant le filtrage des restrictions par période, ce sujet est revenu. On constate à nouveau que la juxtaposition des périodes des arrêtés et des restrictions dans notre modèle complexifie inutilement l'UX. Je propose une nouvelle fois de supprimer les périodes (dates de début et fin) associés aux arrêtés pour ne conserver que celles attachées aux restrictions à l'intérieur des arrêtés. Les dates de début et fin d'un arrêté seraient inférés, quand le besoin se présente, à partir des dates de début/fin des restrictions qui composent l'arrêté (date la plus tôt et date la plus tard). Pour synthétiser mes questions posées ci-dessus, quels seraient les éventuels problèmes posés par la suppression des dates associés aux arrêtés ? Pour l'instant je ne vois que des avantages. |
|
Le principe d'inférer les dates globales quand on en a besoin à partir de celles des mesures fait sens Je ne vois pas d'inconvénient particulier Ça nécessite un retravail du code pour implémenter cette inférence Soit on met à jour ce ticket avec cette décision d'approche (sauf si elle rencontre des objections ?), ou alors on crée un autre ticket ? |
|
Merci Florimond de confirmer qu'à priori il n'y aurait pas d'effet secondaire négatif. Oui un ticket dédié pour définir, explorer, périmétrer, etc. cette proposition de solution au problème, tel qu'il est décrit ici, me paraît bien. Je propose d'attendre la prochaine réunion d'itération (lundi) pour d'abord valider que c'est une priorité et de quelle ordre. |
|
Suite à discussion ce jour on clot ce ticket pour recréer d'autres tickets pour ces sujets
|
|
@johanricher et @florimondmanca voici la maquette de la période à jour avec la description mise à jour, et aussi la label du champ des jours concernés et le bouton dupliquer. https://www.figma.com/design/YuT6Uh4wxe90U8LaPLlDzO/Dialog?node-id=6855-34911&t=zqjGc5uwNFkOJ9fB-1 
|
Description
Suite à
Dans DiaLog les arrêtés ont une date de début et une date de fin, demandées en première étape de la création d'un arrêté :
Cette fonctionnalité permet à la notion d' "arrêté permanent" d'exister dans Dialog : actuellement il s'agit d'un arrêté sans date de fin.
Cependant, "arrêté permanent", en tant que notion métier mentionnée sur les arrêtés papier, n'a pas d'existence juridique ou de quelconque définition précise sur laquelle on aurait vocation à baser notre modélisation de données.
Par ailleurs, chaque mesure d'un arrêté (donc chaque article de l'arrêté s'il y a plusieurs mesures) a vocation à être définie par une date de début et de fin et c'est également ce que permet DiaLog qui, de ce fait, demande à la fois de définir des dates de début/fin au niveau de l'arrêté et au niveau de chaque mesure. Cela provoque des incohérences entre ces différentes dates (qu'on ne vérifie pas), de la confusion pour les utilisateurs et d'autres problèmes d'UX.
La définition d' "arrêté permanent" semble de fait être : "arrêté dont au moins une mesure est permanente (= n'a pas de date de fin)". Par conséquent, la notion même de dates de début/fin d'un arrêté semble ne pas avoir ni d'intérêt ni d'importance à part entière. Pour notre modèle de données et pour l'UX de notre produit c'est donc une contrainte inutile dont on semble pouvoir s'abstraire.
2 options différentes envisageables à ce stade :
The text was updated successfully, but these errors were encountered: