Closed camillemonchicourt closed 2 years ago
Il est intéressant que Geotrek puisse être connecté avec d'autres outils et d'autres sources de données, et c'est une volonté du projet que de le penser dans un éco-système d'outils complémentaires. Il existe déjà plusieurs interfaçages de Geotrek (https://geotrek.ecrins-parcnational.fr/rencontres/2019/presentations/08-geotrek-interfacages.pdf) et il est souhaité enrichir dans ce sens.
C'est pourquoi nous sommes favorables à interfacer Geotrek avec Suricate. C'est donc une bonne chose que Geotrek-admin puisse envoyer ses signalements à Suricate et intéressant que l'inverse soit possible aussi (que Geotrek-admin puisse recevoir les signalements de Suricate).
Cependant quand on interface 2 outils, il faut veiller à ce que ces derniers soient complémentaires et non pas redondants et à ne pas les rendre dépendants. Sinon il faudra ensuite les maintenir en parallèle, en double et à l'identique. Et un changement dans un outil va s'imposer à l'autre si ils sont redondants.
Même si le workflow proposé ci-dessus a été simplifié par rapport aux premières versions, je trouve qu'il reste complexe et qu'il y a une importante redondance avec les 2 outils et donc cela soulève les risques de dépendance et de maintenance. Mais si cet interfacage est optionnel et suffisamment paramétrable, pourquoi pas.
Voici mes remarques sur les différents points :
Depuis deux semaines, grâce à la mise en place de la V2 de SURICATE, je suis coordinateur des signalements sur mon territoire de PNR. J'ai donc pu utiliser l'interface de SURICATE pour administrer les signalements non traité depuis 2016 sur mon territoire. Je trouve cette V2 bien fonctionnelle! Pour moi pas de soucis pour utiliser les deux systèmes de signalement en parallèle et pour le moment je ne vois pas de besoin de faire des échanges entre ma plateforme de gestion Geotrek-Admin et Suricate. Par contre je me permet quelques remarques côté développement souhaité surtout sur Geotrek et en réaction aux derniers points développés par Camille:
Le Département du Gard va déposer prochainement la version finale du Workflow du développement pour intégrer les signalements de Suricate dans Geotrek pour générer une intervention Geotrek
Projet présenté lors des rencontres Geotrek 2021 : https://geotrek.ecrins-parcnational.fr/rencontres/2021/presentations/11-geotrek-suricate.pdf 3 modes de fonctionnement sont maintenant en place, (voir la documentation - https://geotrek.readthedocs.io/en/master/advanced-configuration.html#feedback-reports-settings), illustrés par @Chatewgne ci-dessous :
On pourra désormais choisir entre 3 modes de fonctionnement (contre 2 jusqu'à présent).
La sélection du mode se fait par le biais de variables de configuration.
Un schéma complémentaire sur la suite de la mise en place du mode opératoire (à venir) - envoyer toutes les informations de traitement vers Suricate au cours du cycle de vie du signalement géré depuis Geotrek
Par rapport aux remarques de @JoelAtche sur les envois de mail, je ne sais pas si vous avez été tenu au courant depuis, mais l'API mise en place côté Suricate permet de demander un envoi de mail, donc la sentinelle reçoit un mail en provenance du site Suricate même si l'action a été enclenchée via Geotrek.
Le développement avance sur cette branche https://github.com/GeotrekCE/Geotrek-admin/pull/2896
Etapes et avancement sous forme de board ici : https://github.com/GeotrekCE/Geotrek-admin/projects/7
Pour référence la schématisation du workflow (numéros de bascules en rouge référencées dans le board)
Je m'interroge sur les statuts. Ils sont très liés à ce type de fonctionnement assez spécifique au CD30. Mais du coup tout le monde aura tous ces statuts de signalement par défaut ? Et ce fonctionnement ajoutera t-il des champs dans le module Signalement qui s'imposeront à tout le monde ?
OK je viens de voir les évolutions. Ça m'embête un peu que l'on ait des champs dans la BDD Geotrek qui font référence à "Suricate", mais surtout si ils apparaissent dans l'interface et les exports quand on n'utilise pas ce mode de fonctionnement très lié à Suricate, ce qui sera le cas de la grande majorité des utilisateurs de Geotrek à priori.
Les statuts sont synchronisés via l'API Suricate donc seuls les utilisateurs qui activent ce mode les auront. Pour les champs en BDD, je suis bien obligée de les créer, la plupart de ces colonnes resteront vides si on active pas le mode gestion. Pour les exports on peut considérer qu'on ne les exporte pas par défaut, et que les ajouter aux exports fait partie de la configuration d'activation du mode
OK pour les statuts, merci.
Pour les champs dans la BDD, je comprends bien sur qu'il faille les créer et tout le monde doit avoir la même BDD. Peut-être pour chipoter et éviter d'avoir du SURICATE dans Geotrek, on pourrait être plus générique comme en les nommant du genre externally_created
et external_last_updated
, mais peut-être que je chipote et qu'il vaut mieux assumer que la BDD de Geotrek a une adhérence potentielle à Suricate. C'est pas idéal, mais pas d'avis tranché sur le sujet.
Si on peut masquer un peut partout ces champs par défaut, en effet ça serait bien. Car si 95% des utilisateurs n'utilisent pas ce workflow Geotrek <> Suricate, ça va être confusant pour les utilisateurs de voir ces champs Suricate.
Globalement, avant de merger, il serait intéressant d'indiquer les évolutions que cela va entraîner dans Geotrek-admin, notamment celles qui vont concerner tout le monde, même sans que le mode SURICATE_MANAGEMENT_ENABLED
soit activé.
Car j'ai du mal à y voir bien clair sur le sujet.
On a évoqué plus haut, que cela ajouterait quelques champs non utilisés, à masquer par défaut idéalement. Mais cela va aussi revoir les listes de valeurs installées par défaut de certains champs existants ou autre ?
Le présent document vient décrire le nouveau mode de fonctionnement appelé Suricate Workflow, qui permet d’utiliser Geotrek pour répartir et organiser la prise en charge des signalements entre différents acteurs du territoire, tout en maintenant une synchronisation constante des informations avec Suricate.
Le mode Suricate Workflow de Geotrek définit un processus opératoire strict, composé d’une succession d’étapes représentant le cycle de vie d’un signalement, de sa création jusqu’à sa clôture. Le signalement est constamment caractérisé par un statut qui décrit l'avancement de son traitement et correspond à une couleur particulière sur la carte.
Un signalement est composé des éléments suivants :
Suricate est l’application nationale rassemblant ces signalements. Elle expose une API destinée à la communication avec d’autres applications. Pour que Geotrek puisse communiquer avec Suricate, il faut donc être en possession de clés d’API qui y donnent l’accès.
Le workflow définit trois catégories d’acteurs :
Chaque nuit, Geotrek récupère via l’API Suricate les nouveaux signalements et les mises à jour de signalements existants. Le responsable reçoit un e-mail automatique listant les nouveaux signalements (statut “Déposé”). Il peut se rendre sur Geotrek pour les visualiser sur la carte.
Affecter : Le responsable sélectionne un gestionnaire parmi un menu déroulant, et entre un message lui fournissant des instructions ou informations supplémentaires. Le gestionnaire reçoit un e-mail le notifiant qu’un signalement lui a été affecté, accompagné du message du responsable. Le responsable entre également un second message destiné à la sentinelle pour l’avertir de la prise en charge. Le signalement passe au statut “En cours de traitement”. Suite à l'affectation, on peut passer aux étapes suivantes.
Le gestionnaire se connecte sur Geotrek et crée une Intervention associée au signalement qui lui est assigné, avec une date de planification. L’Intervention a pour statut "Planifiée". Si trop de temps s’écoule entre l’affectation et la création de l’intervention, alors le signalement passe au statut “Intervention en retard” de couleur rouge, et le gestionnaire reçoit un e-mail de rappel.
Le gestionnaire revient sur l’intervention et la bascule au statut "Terminé". Le responsable reçoit un e-mail l’avertissant qu’un signalement est prêt à être clôturé. Si trop de temps s’écoule entre la programmation de l’intervention et sa résolution, alors le signalement passe au statut “Résolution en retard” de couleur rouge, et le gestionnaire reçoit un e-mail de rappel.
Suite à la résolution de l’intervention, le responsable vient confirmer la fin de la prise en charge en marquant le signalement comme “Résolu”. Il entre un message pour la sentinelle confirmant la résolution du problème. Le signalement est considéré comme clos.
A tout moment, le responsable ou le gestionnaire peuvent préciser la position GPS du signalement. Une relocalisation GPS en dehors du territoire défini comme étant la zone de responsabilité cause automatiquement le rejet du traitement du signalement (voir partie 1 Qualification). De plus, il est désormais possible d’afficher la couche de signalements sur les autres modules Geotrek, par exemple pour comparer la position GPS d’un signalement avec celle d’une signalétique ou d’un itinéraire.
Lorsqu’un gestionnaire se connecte à Geotrek, il n’a de visibilité que sur les signalements lui étant actuellement affectés. Le responsable et les comptes administrateurs ont la visibilité sur tous les signalements existants.
Nous avons vu que le responsable entre dans Geotrek des messages à destination des gestionnaires et de la sentinelle. Ces messages peuvent être pré-définis dans l’interface d’administration et sélectionnés via un menu déroulant, puis modifiés avant envoi. Il est possible de récupérer automatiquement dans un message prédéfini la date de résolution de l’intervention associée au signalement ainsi que le nom du gestionnaire.
Bien que le workflow soit strict, la configuration des éléments suivants est possible: Via l’interface d’administration :
Via la configuration de l’application
La communication entre les deux applications est organisée de la manière suivante :
Maintenir la communication entre Geotrek et Suricate nous confronte aux challenges d’une architecture logicielle distribuée, qui, si elle favorise le partage de l’information, demande un grand effort de synchronisation entre les différents relais de cette information. A tout moment, la communication entre les deux applications peut échouer, ce qui implique que Geotrek et Suricate ne seront plus en accord sur le statut d’un signalement. La plupart du temps, il s’agit simplement de problèmes réseaux temporaires.
Pour faire face à cela, un système de reprise des pertes a été mis en place. En cas d’échec de l’envoi d’une information vers Suricate, la requête est stockée et un nouvel envoi est retenté quelques heures plus tard. En cas de rupture durable de la communication, des commandes Django sont disponibles pour qu’un administrateur fasse des tests de connexion et renvoie les informations une fois le problème identifié et résolu.
Geotrek devient un outil pour la prise en charge des signalements Suricate. Il automatise un processus opératoire mis en place dans le Gard, qui défini la répartition des responsabilités entre le département et ses communautés de communes, l'organisation, la notification des partis impliqués. L'implémentation se veut à la fois stricte dans le déroulement des étapes pour garantir le bon traitement des signalements et la non-pollution de la base de données Suricate, tout en donnant de la flexibilité dans sa configuration et sa personnalisation afin de pouvoir être adapté à d'autres territoires et structures.
Pour la configuration technique du mode, se référer à la documentation : https://geotrek.readthedocs.io/en/master/install/advanced-configuration.html#feedback-reports-settings
This document describes a new interface mode between Geotrek and Suricate, called Suricate Workflow. It allows using Geotrek in dispatching feedback reports between supervisors tasked with handling them, whilst maintaining synchronization with a remote report database called Suricate.
Suricate Workflow mode defines a strict process, composed of several steps representing the lifecycle of a user report, from creation to closing. A report is always characterized with a status, depicting how far in the process the report is, and displayed using a specific color on the map.
A report consists of the following information :
Suricate is the French national database gathering such reports. It exposes an API for external software to connect to. For Geotrek to connect to Suricate, you need to request two pairs of API keys allowing access.
This workflow defines three stakeholders categories :
Any Geotrek user account can be used as a supervisor, as long as they have proper access and modification rights on both Report and Intervention modules. There can only be one Manager.
Every night, Geotrek fetches new reports and updates through Suricate API. The manager receives an e-mail listing new reports (with “Filed” status). They can visualize them on Geotrek.
The manager has three options when handling a newly filed report:
The supervisor logs onto Geotrek and creates an Intervention linked to the assigned report, with a planification date. The intervention has status “Plannified”. If too many days have passed between report assignation and intervention creation, the report is automatically set to “Late intervention” status, marked with color red, and the supervisor receives a reminder by e-mail.
The supervisor sets their intervention to “Resolved” status. The manager receives an e-mail notifying that a report is ready to be closed. If too many days have passed between intervention creation and intervention resolution, the report is automatically set to “Late resolution” status, marked with color red, and the supervisor receives a reminder e-mail.
Following the intervention’s resolution, the manager has to confirm the report was handled and sets it to “Resolved”. They enter a message for the sentinel to inform them that the report’s processing is over. The report is considered closed.
At any point, the manager or the supervisor can re-define GPS location for the report. Relocating it outside of the district marked as workflow responsibility area causes the treatment to be rejected (see part 1 Qualification). Furthermore, it is now possible to display the report layer on other Geotrek modules, for instance to compare positions between reports and signages or treks.
When a supervisor logs in to Geotrek, they can only see reports that are currently assigned to them. Both the manager and administrators can see all existing reports.
As we have seen above, the manager enters messages destined to the sentinel or to supervisors. These messages can be predefined in the administration interface and picked from a drop-down selector, then modified before sending. It is possible to automatically retrieve in a message the intervention date and the username of the supervisor that handled it.
Even though the workflow is a strict process, the following items are customisable. Through administration interface :
Through application configuration :
Communication between Suricate and Geotrek operates as follows :
Maintaining synchronization between Suricate and Geotrek confronts us to the challenges of distributed software architecture. At any point, the connection between both applications can be lost, meaning that Suricate and Geotrek will no longer agree on a report’s status. Most of the time, this is simply due to temporary network failure. A system is in place to compensate for such failures. If a request to Suricate API fails, it is stored in the database and resent a few hours later. In case of a long term loss of connection, Django commands are available for an administrator to run some connection tests and resend stored information once connection is recovered.
Geotrek becomes a tool to handle Suricate user reports. It automates a process in place in Gard department in France, defining responsibility between stakeholders, planning, and notification of everyone involved. The implementation is both strict in the sense that all steps are defined and mandatory, in order to ensure proper processing of reports and avoid polluting Suricate database, whilst being customisable to adapt to other territories and structures.
For technical documentation refer to : https://geotrek.readthedocs.io/en/master/install/advanced-configuration.html#feedback-reports-settings
Intégré dans la 2.82.0.
Depuis sa version 2.33.13, Geotrek-admin permet de paramétrer l’envoi automatique des signalements à Suricate (https://github.com/GeotrekCE/Geotrek-admin/issues/2184).
Le CD30 souhaite maintenant enrichir ces premières fonctionnalités d'échanges de données entre Suricate et Geotrek-admin, en permettant aussi de récupérer dans Geotrek-admin les signalements venant de Suricate et en pouvant interagir sur les statuts des signalements.
Le workflow ci-dessous décrit le cas où l’envoi et la récupération des signalements vers et depuis Suricate sont activés :
L’historique des changements de position et de statut effectués dans Geotrek-admin est horodaté, enregistré et affiché (quid des changements effectués dans Suricate directement ?).
1. Signalement sur Geotrek-rando
Une sentinelle crée un signalement sur Geotrek-rando. Geotrek-rando envoie ce signalement à Geotrek-admin. Geotrek-admin envoie ce signalement à Suricate. -ou- Signalement Suricate Une sentinelle crée un signalement sur le site sentinelles.sportsdenature.fr ou sur l’application mobile Suricate. Geotrek-admin récupère bien le signalement sur Suricate
2. Antispam et récupération
Suricate envoie un mail à la sentinelle. La sentinelle valide le signalement en cliquant sur le lien dans ce mail (procédure antispam). Geotrek-admin récupère le signalement depuis Suricate (une fois par jour). Les nouveaux signalements sont créés avec le statut « Nouveau » (couleur à définir dans les liste des statuts, rouge pour signaler la nécessité d’une intervention par le CD30 ?).
3. Recalage géographique
Éventuellement, le département corrige la position GPS dans Geotrek-admin. Geotrek-admin modifie la position GPS dans Suricate.
4. Affectation
Le département valide le signalement, et l’affecte à une structure gestionnaire choisie dans une liste déroulante. Un message type « traitement en cours » destiné à la sentinelle est généré et peut être modifié par le CD30 avant envoi. Le compte à rebours (fonctionnalité optionnelle) est démarré pour la prévision de la date de correction et pour la date de correction elle-même. Geotrek-admin met à jour le statut à « En cours de traitement » dans Suricate. Ce statut est associé à une couleur définie dans la liste des statuts (par défaut orange pour le statut « en cours »). Cette couleur qui identifie chaque signalement est visible sur la liste et sur la carte des signalement. Geotrek-admin envoie à suricate un message automatique non visible par la sentinelle qui indique à quelle structure gestionnaire il a été affecté. Geotrek-admin envoie à suricate le message type destiné à la sentinelle. Dans la nuit, Geotrek-admin notifie le gestionnaire par email. -ou- Classement sans suite Le département classe le signalement sans suite. Un message « refus » destiné à la sentinelle est généré parmi un choix de plusieurs propositions types et peut être modifié par le CD30 avant envoi. Geotrek-admin met à jour le statut à « Classé sans suite » dans Suricate (couleur grise). Geotrek-admin envoie à suricate le message type destiné à la sentinelle.
5. Expiration du délai de programmation
Si un délai de programmation a été configure (fonction optionnelle, désactivée par défaut, configuré à 30 jours pour le CD30) et qu’il s’est écoulé depuis le point 4, le signalement passe dans le statut de Geotrek-Admin « Programmation d’intervention en retard » (sans changement de statut dans Suricate). Ce statut est associé par défaut à la couleur rouge dans la liste et sur la carte. Dans la nuit, Geotrek-admin notifie le gestionnaire par email.
6. Programmation de l’intervention
Le gestionnaire crée une intervention liée au signalement avec le statut Geotrek- Admin « Programmée » et y associe une date prévisionnelle de résolution (sans changement de statut dans Suricate). Le statut du signalement passe à « programmé ». Ce statut est associé par défaut à la couleur verte dans la liste et sur la carte. La fiche du signalement affiche un lien vers le(s) intervention(s) liées et inversement.
7. Traitement
Éventuellement, le gestionnaire corrige la position GPS dans Geotrek-admin. Geotrek-admin modifie la position GPS dans Suricate. Le gestionnaire utilise le module intervention de Geotrek admin pour réaliser le suivi.
8. Expiration du délai de résolution
Si un délai de résolution a été configure (fonction optionnelle, désactivée par défaut, configuré à 180 jours pour le CD30) et qu’il s’est écoulé depuis le point 4 (Affectation au gestionnaire), le signalement passe dans le statut intervention de Geotrek « Résolution en retard ». Ce statut est associé par défaut à la couleur rouge dans la liste et sur la carte. Dans la nuit, Geotrek-admin notifie le gestionnaire par email. (sans changement de statut dans Suricate).
9. Déclaration d’intervention terminée
Le gestionnaire déclare l’intervention comme terminée. Si cette intervention est liée à un signalement, un message automatique “Intervention terminée” (sans changement de statut dans Suricate statut toujours “en cours de traitement” ), non visible par la sentinelle est envoyé au Département pour l’informer.
10. Validation de la résolution
Le département valide la résolution du signalement et change le statut en “résolu” Geotrek-admin met à jour le statut à « Résolu » dans Suricate. Une message automatique destiné à la sentinelle pour l’informer de la date de résolution est envoyé à Suricate
Pendant tout le processus, le département conserve la main et peut revenir si besoin à l’étape 4 en cas de mauvaise affectation.
Toutes les nuits :
Individuellement, chaque signalement fait l’objet d’un code couleur visible sur la liste et la carte. Si le signalement est à programmer après affectation par le Département, l’indicateur est orange. Si le signalement est en retard de programmation ou de résolution, l’indicateur est rouge. Les délais et les couleurs sont désactivable et configurables.
Du point de vue de Suricate, un seul utilisateur apparaît : le département. Les actions des gestionnaires donnent lieu à une mise à jour des statuts et messages dans Suricate, mais cela se fait sous le couvert du département. Aucun mail n’est envoyé directement par Geotrek à la sentinelle. A priori, Geotrek n’a même pas besoin de connaître l’adresse de la sentinelle.
La proposition d’API faite par ARUT@M sera à affiner en fonction du fonctionnement décrit ci-dessus. Certaines fonctionnalités prévues sont inutiles, d’autres sont à préciser, en particulier pour optimiser le processus de récupération des signalements depuis Suricate.