Workflow des signalements entre Suricate et Geotrek-admin

[camillemonchicourt]

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 :

• Geotrek-admin récupère les nouveaux signalements auprès de Suricate (ainsi que les changement de statut effectués directement dans Suricate ?)
• Geotrek-admin envoi un mail à chaque gestionnaire pour lister les nouveaux signalements et les signalements arrivés à expiration.

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.

[camillemonchicourt]

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 :

1. OK. A voir comment bien filtrer les signalements venant de Suricate pour arriver à ne récupérer que ceux qui concernent notre territoire ou notre structure
2. OK. Pour la couleur des statuts des signalements, je propose de les définir dans la table des signalements. Comme ça si un Geotrek-admin utilise d'autres types de statut, sans forcément utiliser les liens avec Suricate, il pourra leur associer les couleurs qu'il souhaite.
3. OK, mais il s'agit de la localisation directe sur la carte, pas en passant par des coordonnées GPS.
4. Il faut voir comme gérer la liste des gestionnaires. Si on se base sur la table existante des organismes ou si on créé une table dédiée. Peut-être une table dédiée si les gestionnaires ciblés ne sont pas forcément les même que les organismes existants ? Et surtout si il faut ajouter des champs dans cette table, notamment une adresse email de destination des alertes ? 4bis. J'avais retenu qu'on réservait les échanges entre Suricate et la sentinelle à Suricate et que Geotrek-admin n'avait aucun échange avec la sentinelle. Cela me semble préférable. Je laisserai donc plutôt Suricate envoyer le message "Traitement en cours" ou "refus" à la sentinelle, sans message type envoyé par Geotrek-admin, pour simplifier.
5. OK.
6. OK mais à voir comment lier les statuts des signalements avec les statuts des interventions qui peuvent être customisés dans les tables de la BDD et donc différents d'un Geotrek-admin à l'autre.
7. OK
8. OK
9. Quand l'intervention liée au signalement est terminée, cela ne change pas automatiquement le statut du signalement ?
10. Là aussi je laisserai à Suricate la partie information de la sentinelle

[JoelAtche]

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:

1. Suricate affecte les signalements aux territoires (commune, ComCom, PNR, Département) et informe les administrateurs en fonction du territoire qui leur est affecté, donc seul les signalements du territoire du Geotrek-admin pointé seront récupéré.
2. Ok avec Camille il est important que les types de signalements sur Geotrek-Admin ne soient pas imposé par SURICATE. Et ok pour les couleurs même si par sûr d'utiliser cette possibilité.
3. RAS pour moi vu que je ne penses pas faire d'échange entre les deux outils, mais il est vrai que les positions faites avec l'appli Suricate restent souvent aléatoire...
4. je confirme que pour moi il ne faut pas que Geotrek-admin envoie des messages à la sentinelle, les fonctionnalités sur Suricate sont bonnes et suffisantes, pas besoin de compliquer. Et une sentinelle de SURICATE n'a pas être "contacté", "informé" par un autre site internet que Suricate, et à mon avis cela pourrait même être interprété commune du piratage de son adresse mail, et du coup la décourager de faire des signalements, ce qui serait contre productif!
5. Cette fonction doit bien rester optionnelle.
6. RAS car pour le moment on ne transforme pas les "signalements" en "interventions" sur notre Geotrek-Admin. On intervient sur le signalement et on fait évoluer son statut, puis on informe le signaleur par mail directement.
7. RAS
8. RAS
9. RAS
10. OK avec remarque de Camille, c'est toujours Suricate qui doit informer la sentinelle!

[DepartementGardSAPN]

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

[camillemonchicourt]

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

• Le premier mode fonctionne sans Suricate : (mode existant)

• Le deuxième mode (Suricate Signalement) transfère à Suricate comme jusqu'à présent : (mode existant)

• Le troisième mode (Suricate Gestion) permet la mise en place progressive du mode opératoire du CD30 : (nouveau mode)

La sélection du mode se fait par le biais de variables de configuration.

[Chatewgne]

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.

[Chatewgne]

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)

[camillemonchicourt]

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 ?

[camillemonchicourt]

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.

[Chatewgne]

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

[camillemonchicourt]

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.

[camillemonchicourt]

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 ?

[Chatewgne]

La version finale du schéma du workflow

Geotrek pour le traitement des signalements

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.

I - Les signalements

Un signalement est composé des éléments suivants :

• Une position GPS
• Un message décrivant le problème
• Une catégorie : balisage, environnement, sécurité, conflit d’usage
• Une magnitude : utilisation possible, difficile, ou impossible
• Une pratique : randonnée pédestre, cyclisme, aviron…
• Jusqu’à 3 photos

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.

II - Définition des acteurs et leur responsabilité

Le workflow définit trois catégories d’acteurs :

• la sentinelle : il s’agit de la personne qui a soumis le signalement. Elle n’a pas de compte utilisateur Geotrek et n’intervient pas dans le traitement, mais est tenue informée de l’avancement du traitement via des e-mails semi-automatiques.
• les gestionnaires : ils sont responsables du traitement d’un (ou plusieurs) signalement(s). Il leur incombe de planifier une intervention sur le terrain et d'entrer sur Geotrek les informations relatives à cette intervention pour assurer le suivi.
• le responsable : il est chargé de garder une vision d’ensemble des signalements sur le territoire, d’assigner chaque signalement à un gestionnaire, de gérer les communications envers la sentinelle, et de confirmer la résolution des signalements.
• Tout compte utilisateur Geotrek peut représenter un gestionnaire, à condition d’avoir les droits de création et de modification sur les modules Intervention et Signalement, mais il ne peut y avoir qu’un seul responsable. Dans le premier cas d’usage, le responsable est le département du Gard, qui va répartir les signalements vers différentes Communautés de Communes - les gestionnaires.

III - Le traitement du signalement

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.

1 - Qualification

• Lorsque le responsable est face à un nouveau signalement (statut “Déposé”), trois possibilités s’offrent à lui :
• Classer sans suite : Le signalement n’est pas pertinent, le responsable passe le signalement au statut “Classé sans suite” et entre un message pour la sentinelle expliquant ce choix. Le signalement est considéré comme clos.
• Rejeter le traitement : Le signalement ne concerne pas un équipement ou un espace sous la responsabilité des utilisateurs du Workflow, mais pourrait éventuellement être traité par un autre acteur de la communauté Suricate. Il est exclu du workflow Geotrek mais accessible au reste de la communauté via d’autres outils utilisant l’API Suricate.

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

  2 - Programmation

  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.

  3 - Résolution

  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.

  4 - Clôture

  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.

  5 - Relocalisation GPS

  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.

  6 - Visibilité des signalements

  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.

  7 - Messages prédéfinis

  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.

IV - Configuration du workflow

Bien que le workflow soit strict, la configuration des éléments suivants est possible: Via l’interface d’administration :

• le choix des couleurs associées à chaque statut
• la sélection du responsable (manager de gestion)
• la sélection de la zone géographique (secteur de gestion)
• les messages prédéfinis

Via la configuration de l’application

• les clefs d’API permettant de se connecter à Suricate
• l’activation du mode Workflow ou d’un autre mode de fonctionnement
• l’activation de l’utilisation des différentes couleurs selon le statut
• les délais du passage aux statuts “En retard”

V - Synchronisation et reprise des pertes

La communication entre les deux applications est organisée de la manière suivante :

• Suricate vers Geotrek : les nouvelles informations sont reçues une fois par nuit
• Geotrek vers Suricate : chaque modification d’un signalement sur Geotrek est envoyée immédiatement vers Suricate

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.

Conclusion

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

[Chatewgne]

Geotrek for user reports processing

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.

I - Reports

A report consists of the following information :

• A GPS position
• A message describing the problem
• A category : environment, security, usage conflit, signages
• A magnitude : usage is possible, difficult, or impossible
• A practice : trekking, cycling, horse-riding…
• Up to 3 pictures

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.

II - Stakeholders and responsibility

This workflow defines three stakeholders categories :

• the sentinel : the person who submitted the report. They do not have a Geotrek user account nor intervene in the workflow, but they are kept updated on the processing of their report via semi-automatic e-mails.
• supervisors : they are assigned (a) report(s) for treatment. They are tasked with planning an Intervention on Geotrek and enter information about it.
• the manager : they maintain a global view of all reports on the territory, assign reports to supervisors, handle messaging to the sentinel, and confirm reports resolution.

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.

III - Report processing

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.

1 - Qualification

The manager has three options when handling a newly filed report:

• Classify : The report isn’t relevant. The manager sets the report to “Classified” and enters a message for the sentinel, explaining their choice. The report is considered closed.
• Reject treatment : The report does not involve an area or an equipment under responsibility of the workflow users, but could be handled by another member of the Suricate community. The report is excluded from Geotrek workflow but is still accessible to the community via other applications using Suricate API.
• Assignation : The manager selects a supervisor from a drop-down selector, and enters a message with instructions or further information. The supervisor receives an e-mail notifying them about the newly assigned report, along with the manager’s message. The manager also enters a message destined to the sentinel, to notify them that the report is about to be handled. The report is set to status “Waiting”. Only after assignation can we proceed to the following steps.

2 - Planification

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.

3 - Resolution

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.

4 - Closing

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.

5 - GPS relocalisation

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.

6 - Reports visibility

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.

7 - Predefined messages

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.

IV - Workflow configuration

Even though the workflow is a strict process, the following items are customisable. Through administration interface :

• colors for each status
• selecting the manager
• selecting the workflow responsibility area
• predefined messages

Through application configuration :

• API keys to connect to Suricate
• enabling of Workflow mode or any other mode
• enabling/disabling status colors on map
• duration of timers setting reports to “late” statuses

V - Synchronization and network losses

Communication between Suricate and Geotrek operates as follows :

• Suricate to Geotrek : new information is fetched once a night
• Geotrek to Suricate : every report update on Geotrek is immediately forwarded to Suricate

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.

Conclusion

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

[camillemonchicourt]

Intégré dans la 2.82.0.