Evolutions Signalements / Perturbations

[camillemonchicourt]

Nous explorons actuellement la possibilité d'identifier les sentiers et itinéraires impraticables liés à des perturbations, à partir des signalements. En lien avec https://github.com/GeotrekCE/Geotrek-admin/issues/3879. Le fait de passer par des buffers (zones tampon) autour des signalements et de les intersecter avec les tracés des sentiers et des itinéraires a clairement des limites et effets de bord, mais c'est une première exploration intéressante.

Pour cela, je me suis replongé dans le module Signalements, que nous utilisons peu et j'avais suivi de loin toutes ses évolutions liées à la mise en place du mode "Workflow Suricate" (https://github.com/GeotrekCE/Geotrek-admin/issues/2366).

Dans notre cas, nous avons quelques signalements qui proviennent des différents Geotrek-rando branchés sur notre Geotrek-admin. Et nous allons faire saisir aux agents les dégâts et perturbations directement dans le module Signalement. Or cela a actuellement plusieurs limites et nous souhaiterions donc :

• Ajouter un champs "Structure" dépendant de la personne ayant saisi le signalement (si saisi dans GTA)
• Rendre le champs "Email" non obligatoire (et masquable en saisie), car on saisit un signalement depuis GTA, cela n'a pas de sens de renseigner un email, hors il est actuellement obligatoire
• Ajouter un filtre par année (basé sur la date de création) et éventuellement par plage de dates
• Trier les signalements dans la liste par défaut par date décroissante
• Ajouter un champs "Fournisseur" (provider). Voir https://github.com/GeotrekCE/Geotrek-admin/issues/3953
  • Si saisi dans Geotrek-admin > Provider = Geotrek-admin
  • Si saisi dans un portail GTR > Provider = Nom du portail GTR (il peut y en avoir plusieurs branché sur un même GTA)
  • Si import depuis Suricate > Provider = Suricate
  • Ajouter filtre par provider
  • Ajouter Provider dans les fiches détails, les exports...
• Améliorer l'email envoyé automatiquement à la création d'un signalement
  • Ajouter l'éventuel nom de la Rando
  • Ajouter un lien vers l'URL du signalement dans GTA
  • Ajouter l'éventuel Créateur (si saisi dans GTA)
  • Ajouter le Fournisseur (provider)
• Actuellement les signalements comprennent aussi des champs "Gestionnaire" et "Lancer le compte à rebours" Ces champs me semblent liés au mode Workflow, même si j'ai du mal à les comprendre. Je trouve bizarre (et non souhaitable et donc problématique) un champs affichant tous les utilisateurs du GTA et leur email. Et un champs booléen "Lancer le compte à rebours" qui lance une action me parait aussi bizarre et discutable. C'est pour cela que je propose d'à minima les masquer par défaut si le mode Workflow n'est pas activé.

A faire aussi ?

• https://github.com/GeotrekCE/Geotrek-admin/issues/1088
• https://github.com/GeotrekCE/Geotrek-admin/issues/1098
• https://github.com/GeotrekCE/Geotrek-admin/issues/1298

[babastienne]

1. Ajouter un champs "Structure" dépendant de la personne ayant saisi le signalement (si saisi dans GTA)
2. Rendre le champs "Email" non obligatoire (et masquable en saisie), car on saisit un signalement depuis GTA, cela n'a pas de sens de renseigner un email, hors il est actuellement obligatoire

Pour ces deux points on voit clairement que le module a été pensé initialement pour recevoir des données "externes" et pas vraiment pour une saisie interne.

1. Ok pour moi, mais si on rend ce champ obligatoire à quelle structure seront rattaché les signalements externes ? La structure par défaut définie dans le custom.py ?
2. Ok pour rendre le champ optionnel dans l'interface mais il faudra qu'il reste obligatoire sur les formulaires externes, donc à voir comment mettre ça en place.

4. Trier les signalements dans la liste par défaut par date décroissante

C'est déjà possible de trier par colonne "date de modification", mais il faudrait le faire par défaut, ok pour moi. Est-ce qu'on tri par date de modification ou de création ?

5. Ajouter un champs "Fournisseur" (provider).

Dans le cas des contributions externes via portail je ne suis pas sur que ce soit une information demandées / renvoyée avec la requête sur l'API, donc peut-être pas si simple ? Cela porurait impliquer une modification du endpoint et également de GTR3. Ou alors on se base sur le header de la requête pour récupérer le origin et on en fait le provider ? A creuser ...

6. Améliorer l'email envoyé automatiquement à la création d'un signalement

Oui ok pour ma part. C'est actuellement un template qui peut être surchargé mais le surcharger par défaut me semble pertinent, et cela implique peut-être aussi des devs pour avoir accès dans le template à des infos supplémentaires.

Est-ce qu'on continue d'envoyer un email même si le signalement est créé directement depuis l'admin ?

7. Masquer les champs du workflow

Oui ok pour moi. A vérifier si c'est en effet nécéssaire de les avoir dans l'interface mais je ne pense pas. A minima les masquer lorsque le workflow n'est pas activé.

[Chatewgne]

Points de vigilance :

• En l'état, si on crée un signalement depuis Geotrek-Admin, et que la connexion entre Suricate et Geotrek est activée, alors ce signalement part vers Suricate -> on ne veut sûrement pas que les perturbations partent vers Suricate, tout en continuant de transmettre les signalements qui viennent de Rando ?

• Les permissions de modification du signalement en mode Workflow ne doivent pas dépendre de la structure de l'utilisateur et du signalement, mais bien de la logique du workflow (c'est le manager OU le gestionnaire qui peut faire une certaine modification selon l'étape où on en est). La structure ne devrait peut-être pas être obligatoire en base, mais seulement dans les formulaires en mode "non-workflow" ? Ou bien obligatoire avec une structure par défaut, mais qui ne sera pas prise en compte pour les permissions quand c'est nécessaire ?

• Si les adresses emails ne sont plus obligatoires, s'assurer que les potentielles exceptions sont bien gérées partout où ces mails sont utilisés. Pour l'instant la création d'un signalement envoie un mail à cette adresse.

• Effectivement Gestionnaire et Compte à rebours devraient être masqués si on n'est pas en Workflow

Il me semble utile, au vu des différences de traitement qu'on va leur appliquer, de pouvoir faire rapidement la différence entre un signalement venu de l'extérieur et une perturbation renseignée par un agent. Ajouter une typologie pour faire la différence entre les deux ? Savoir que le premier est en provenance de Rando, alors que le second a été entré côté Admin, suffit-il toujours à faire la distinction entre ces deux cas ?

[camillemonchicourt]

OK, merci pour ces retours. Au regard de ces éléments, quelques réflexions :

• Le champs "Structure" n'est peut-être pas si essentiel. Il permettrait cependant à s'assurer que des utilisateurs d'une structure ne puissent pas modifier ou supprimer les signalements d'une autre structure.
• En effet si un signalement provient de l'extérieur (Geotrek-rando ou autre) on lui appliquerait la structure par défaut. C'est déjà ce que l'on fait il me semble quand on fait des imports avec les parsers.
• Pour les permissions par structure ou par workflow, je ne sais pas trop. A étudier. Je pense qu'il aurait fallu privilégier une logique et cohérence globale des permissions dans tous les modules de GTA, et ne pas faire des choses spéciales et complexes liées à Suricate, mais je n'ai pas suivi cette partie, et n'ai pas tous les éléments en tête.
• Pour le tri par défaut, j'ai l'impression qu'il faudrait plutôt afficher dans la liste la DATE DE CRÉATION (plutôt que la date de modification) et bien trier par défaut sur cette date de création. Pour avoir par défaut les signalements remontés récemment en haut de liste. La date de modification est une info plus secondaire.
• Oui en effet, il faudrait ajouter côté GTR un provider, ou s'appuyer sur le nom du portail GTR. Pourquoi pas s'appuyer sur le header du post
• Oui, continuer à envoyer un email quand un signalement est créé depuis GTA
• Pour les envois à Suricate, je ne sais pas si ceux créés directement dans GTA ne doivent pas être envoyés. Potentiellement si. On pourrait éventuellement rendre ça configurable en définissant les "providers" des signalements qui sont envoyés ou non vers Suricate ?

---

Pour moi, il n'y a pas forcément tant de différence entre des signalements provenant d'un GTR, de Suricate ou directement saisis dans GTA. Et leur typologie et leurs usages peuvent varier selon les territoires et les contextes. Pour les identifier, le mieux est l'ajout de fournisseurs (providers), il me semble.

[camillemonchicourt]

Suite aux retours, voici les sujets à traiter dans leur ordre de priorité :

1. Rendre le champs "Email" non obligatoire (et masquable en saisie), car on saisit un signalement depuis GTA, cela n'a pas de sens de renseigner un email, hors il est actuellement obligatoire
2. Ajouter un filtre par année (basé sur la date de création) et éventuellement par plage de dates. A faire globalement dans tous les modules car on a ce champs partout ? Peut-être donc dans la colonne de droite car c'est un champs générique et pas spécifique au module ? Faire de même pour le champs "date de modification" tant qu'on y est ?
3. Trier les signalements dans la liste par défaut par date de création décroissante
4. Afficher par défaut la colonne "Date de création" plutôt que "Date de modification"
5. Ajouter un champs "Fournisseur" (provider). Voir https://github.com/GeotrekCE/Geotrek-admin/issues/3953
   • Si saisi dans Geotrek-admin > Provider = Geotrek-admin / Priorité 1. Mais à faire par ailleurs pour les autres modules. Ou plutôt laisser vide quand ça vient de GTA ? A discuter certainement
   • Si saisi dans un portail GTR > Provider = Nom du portail GTR (il peut y en avoir plusieurs branché sur un même GTA) / Priorité 2
   • Si import depuis Suricate > Provider = Suricate
6. Ajouter filtre par provider
7. Ajouter Provider dans les fiches détails, les exports...
8. Améliorer l'email envoyé automatiquement à la création d'un signalement que l'on conserve quand saisi directement dans GTA (important)
   • Ajouter l'éventuel nom de la Rando
   • Ajouter un lien vers l'URL du signalement dans GTA
   • Ajouter l'éventuel Créateur (si saisi dans GTA)
   • Ajouter le Fournisseur (provider)
9. Actuellement les signalements comprennent aussi des champs "Gestionnaire" et "Lancer le compte à rebours"
10. Enrichir les filtres géographiques (https://github.com/GeotrekCE/Geotrek-admin/issues/1298)
11. https://github.com/GeotrekCE/Geotrek-admin/issues/1088
12. https://github.com/GeotrekCE/Geotrek-admin/issues/1098

---

• Si GTA est branché à Suricate, je ne vois pas pourquoi on ne continuerai pas à envoyer ces signalements vers Suricate
• On met de côté l'idée d'ajouter un champs "Structure" ? Cela pose en effet des questions en terme de permissions à cause du mode Workflow, même si cela me pose soucis d'avoir adopter un autre mode de permissions spécifique dans un module Geotrek. A discuter.

[Chatewgne]

Si GTA est branché à Suricate, je ne vois pas pourquoi on ne continuerai pas à envoyer ces signalements vers Suricate

L'adresse mail est requise côté Suricate pour le signalement (c'est pour cela que le champ est obligatoire dans Geotrek) afin d'identifier la sentinelle et lui envoyer les informations de suivi

Si on veut continuer à envoyer à Suricate les signalements faits depuis l'admin, soit il faut leur associer une adresse mail par défaut (utiliser l'adresse mail MANAGER ?) soit conserver le champ obligatoire

[camillemonchicourt]

OK je n'ai pas d'avis sur l'intérêt ou non d'envoyer les signalements créés dans GTA vers Suricate. Mais ce qui est certain, c'est que c'est bloquant que le champs "email" soit obligatoire et qu'il est important pour nous de supprimer cette obligation. Donc je dirai :

• soit ne pas envoyer les signalements créés dans GTA vers Suricate
• soit n'envoyer que ceux qui ont un email
• soit utiliser un email par défaut quand aucun email n'est renseigné

[babastienne]

Pas fan de l'idée d'avoir un email par défaut. Je préfère qu'on envoi les signalements vers Suricate seulement si un email est renseigné, voir pas du tout.

[Chatewgne]

Comment faire pour que cela soit clair ? Rajouter un message en dessous du champs email: "Si vous renseignez une adresse email, ce signalement sera envoyé à Suricate" ?

[camillemonchicourt]

Non non, on ne devrait pas avoir de Suricate dans Geotrek. Ce n'est qu'un cas d'usage et un outil externe. Je ne sais pas bien comment Geotrek fonctionne avec Suricate, mais cela devrait être assez indépendant et ne pas y avoir de référence spécifique à Suricate dans Geotrek. Sinon quand on créé un signalement dans GTA, on ne l'envoie pas à Suricate si c'est plus simple.

[camillemonchicourt]

Différents points ont été traités dans la 2.107.0 :

• Champs "Email" non obligatoire
• Ajout du champs "Provider". Renseigné automatiquement à "Geotrek-admin" si il est saisi dans GTA, ou à "API" si il est posté par l'API (depuis GTR ou autre) + Filtre par "Provider" (Fournisseur)
• Champs "Gestionnaire" et "Lancer le compte à rebours" masqués si on n'est pas en mode Workflow
• Ajout d'un filtre par "Année de création" et "Année de mise à jour"
• Amélioration de l'email par défaut envoyé automatiquement quand un signalement est créé (Ajout de l'éventuel nom de la rando concernée / Ajout du lien vers la fiche détail du signalement / Ajout du fournisseur)

[camillemonchicourt]

Des filtres "Année de création" et "Année de modification" ont été ajoutés, mais il faudrait trier les année de manière décroissante pour avoir les années les plus récentes en haut de la liste (comme c'est le cas dans les filtres des autres modules comme le module Interventions). Et si possible, faire en sorte que la liste des valeurs des filtres passent au dessus de la modale des filtres, car sinon on voit pas facilement la liste de toutes les valeurs :

[camillemonchicourt]

Quelques retours complémentaires sur les évolutions et le fonctionnement actuel :

• J'ai découvert le champs origin et ne comprenait initialement pas à quoi il correspondait. C'est un champ qui vient de Suricate en mode workflow, il stocke le nom de la structure responsable du traitement comme "cd30" ou "pnrml". Il me semble qu'il fait peut-être un peu doublon avec le concept plus global de structure dans Geotrek, mais ce dernier est une clé étrangère et pas un champs texte, donc OK de ne pas avoir nommé ce champs "structure". Mais ce champs origin créé un peu de divergence et de confusion dans la BDD Geotrek selon moi. Donc à voir si on renomme ce champs structure_txt ou autre du genre, pour être plus clair. Car là pour moi origin n'est pas un terme qu'on a par ailleurs dans Geotrek et il apporte de la confusion avec provider selon moi. On laisse comme ça pour le moment.
• Le champs email est désormais optionnel à la saisie (blank=True, default="") mais il est resté en NOT NULL dans la BDD. Idem pour les eid, sync_errors et mail_errors sont en NOT NULL, mais ne devraient pas l'être selon moi. Pour sync_errors et mail_errors c'est 0 la valeur par défaut car c'est un compte d'erreurs. Il serait souhaitable de les changer pour null = True et il manque les valeurs par défaut dans le fichier post_90_defaults.sql. Il est important que la logique des données soit cohérente niveau Django mais aussi BDD. L'identifiant externe (eid) doit être optionnel aussi au niveau BDD. C'est d'ailleurs le cas pour ce même champs eid dans la table trekking.trek où il n'est pas NOT NULL.
• Au niveau BDD, il y a un autre point qui ne va pas selon moi, c'est que external_uuid est autogénéré si non renseigné. Ce champs ne doit servir qu'à importer un UUID externe quand il est fournit par une BDD externe. Donc à ne pas auto-générer si non fourni. Mais plus largement, selon moi ce champs ne devrait pas exister du tout selon moi Justement pour les UUID (Universally Unique Identifier), comme son nom l'indique, il n'en faut qu'un. Soit il est fourni par une BDD externe et on rempli le champs UUID, soit il est pas fourni et on génère le champs UUID. Mais un champs external_uuid ne devrait pas exister, c'est pas la logique des UUID selon moi. Ça c'est le role des external_id que de stocker l'ID spécifique externe de l'objet dans sa BDD de provenance, mais pas external_uuid, on devrait jamais avoir ce champs.
• J'ai des utilisateurs qui ont tous les droits sur le module SIGNALEMENT. Mais quand ils vont dans l'onglet FICHIER LIES d'un signalement qu'ils ont créé, ça leur dit qu'ils ne peuvent pas y ajouter de fichier car l'objet n'est pas de leur structure Hors les signalements n'ont pas de structure (le soucis vient surement de là) et en plus c'est eux-mêmes qui ont créé ce signalement.

[camillemonchicourt]

Dans la 2.107.1 :

• Le champs external_uuid n'est plus généré par défaut si non renseigné. Selon moi, il faudrait cependant le supprimer, car le principe d'un UUID est de n'en avoir qu'un. Un champs external_uuid est contraire au principe d'UUID
• Je préférerai aussi que le champs eid soit passé en NOT NULL comme c'est le cas dans les autres tables (trekking.trek par exemple), par cohérence et plus clairement identifier les champs obligatoires ou non directement au niveau BDD. Idem pour email si possible.
• Les champs email, eid, sync_errors et mail_errors ont des valeurs par défaut
• Les filtres par années sont triés par ordre descendant
• Le soucis des permissions sur les fichiers attachés a été corrigé
• Les valeurs des filtres s'affichent au-dessus de la modale des filtres si ils sont longs