Evolution du module ÉVÉNEMENTS - Compléments et évaluation

[camillemonchicourt]

Le module ÉVÉNEMENTS de Geotrek permet déjà de saisir, gérer et diffuser des événements touristiques (sortie, conférence, atelier, expositions, visites...) sur Geotrek-rando ou autre.

Il est actuellement composé de ces champs :

• id (integer)
• accessibility (string)
• approved (boolean)
• attachments
• begin_date (string($date))
• end_date (string($date))
• booking (string)
• cities (string)
• contact (string)
• create_datetime (string($date-time))
• update_datetime (string($date-time))
• description (string)
• description_teaser (string)
• duration (string)
• email (string($email))
• external_id (string)
• geometry (string)
• meeting_point (string)
• meeting_time (string)
• name (string)
• organizer (string)
• participant_number (string)
• pdf - auto-generated (string)
• portals
• practical_info (string)
• published (boolean)
• sources
• speaker (string)
• target_audience (string)
• themes
• url (string($uri))
• uuid (string($uuid))
• website (string($uri))

L'objectif de ces évolutions est :

• de mieux structurer certains de ces champs
• d'ajouter quelques champs pour mieux décrire les événements
• d'ajouter quelques champs nécessaires au suivi et à l'évaluation des événements touristiques
• de permettre de gérer les réservations des événements touristiques

ÉVOLUTIONS PRÉVUES :

• Organisateur >> Basculer de texte à Liste (n-n), attention aux migrations de données
• Contact >> Basculer de texte à Liste avec nom, adresse, téléphone, email, URL, Actif (booléen), attention aux migration données
• Intervenant : En faire une liste ou on garde un champs libre ?
• Ajouter un champs "Contact de l'intervenant" non diffusé (au niveau des événements ou des intervenants, selon le point précédent)
• Ajouter une "Catégorie" en plus du type ? Plus large que le type (Animation pédagogique, animation pédagogique, formation). Lier les types aux catégories >> Réserves sur le sujet, car complexifierai la compréhension et la saisie. Les types suffisent.
• Remplir date fin automatiquement avec date début (javascript)
• Liste de lieux avec XY prédéfinis permettant de localiser correctement des événements sans les pointer sur la carte ?
• Ajouter "Heure fin" - Supprimer champs durée ?
• Formater les champs horaires
• Réorganiser formulaire (type en haut par exemple)
• "Nombre de places" à basculer en INTEGER
• Réservation : Ajouter BOOL + Texte
• Annulation : Ajouter BOOL + Liste de causes + Texte
• Public visé : en faire une liste / Quel lien avec champs "Accessibilité" ?
• Évaluation : Ajouter les champs "Temps préparation", "Temps d'intervention", "Nombre participants" (par classe d'age avec liste adaptable) / "Provenance du public" ?
• Pouvoir créer des groupes d’événements (= temps fort + projets pédagogiques ou autre)
• Réservations : Tables dédiées avec les inscrits
• Limiter le nombre de caractères du champs "Chapeau" (description_teaser), différemment des autres champs ?
• Finaliser la duplication d'objets depuis l'interface

Ces évolutions devront être réalisées au niveau de la BDD, des formulaires, des fiches détails, des filtres, des exports, de l'API V2, de la synchronisation, et éventuellement reportés sur Geotrek-rando-v3 pour certains champs.

[Chatewgne]

Théo #3247 ✔️

• Réservable : bool (pour aller avec le champ texte existant)
• Si il est activé : afficher les widgets (réservation)
  champ texte réservation -> passer en intéger

Célia 1 #3270 ✔️

• Faire une correction pour toujours afficher le nombre de place

Célia 2 #3273 ✔️

• Si bookable est activé : afficher les widgets de réservation (texte)

Théo 2 #3264 ✔️

• Créer des lieux dans l'Admin
• avoir un lien avec FK + copier la geom dans le formulaire (un peu comme Lieux de renseignement) (mettre tous les Points de Lieux en avance dans la page et afficher le point à la sélection du Lieu en question)
• Exports
• Pouvoir filtrer les events par place dans APIv2
• API /v2/places
• API dans le détail d'event

Amandine #3248 ✔️

• Rendre obligatoire les dates de début -> si pas de date dans les données existantes : set 1970
• Si la date de fin n'est pas présente alors on renvoie la date de début dans l'APIv2
  End date rempli automatiquement

Amandine 2 #3253 ✔️

• Renommer meeting_time en start_time -> attention apiv2
• Rajouter end_time
• TimePicker dans le formulaire pour heure de rdv et heure de fin

Amandine 3 #3252 ✔️

• Contraindre les dates fin doit après début sur les formulaires

Célia #3249 ✔️

• Annulation :
• bool
• liste de causes
• API add to detail cancellation_reason
• description

Amandine #3275 ✔️

• Réorganiser formulaire

Elie #3257

• Refacto crispy formset
• Attention layout des treks cassés
• Blade et Line ?

Elie makinacorpus/django-mapentity#254 #3254

• MapEntity forms / Common Forms

Elie #3250 ✔️

• Rajout d'un onglet "Bilan"
• Nombre de participants effectifs par classe d'âge (avec liste adaptable dans l'admin) (dans un autre onglet ?) Ca va marcher comme les mandays
• attention aux exports
• Fusionner les count facilement ?

Camille

• Changelog
• Relecture et vocabulaire

Amandine #3261 ✔️

• Nombre de participants : devient "description du nombre de places" ?? ( ⚠️ place != participant ⚠️ ) et un nouveau "nombre de places" en integer (BREAKING CHANGE renommage) Essayer de parser un entier, si impossible alors l'ajouter à "Informations pratique" avec "Organisateur : valeur"

Amandine #3268 ✔️

• En dernier, mettre à jour les vues SQL

Célia #3272 ✔️

• Faire un alias pour que le champ meeting_time soit fourni en plus de start_time dans l'API
• Faire un alias pour que le champ participant_number soit fourni en plus de capacity dans l'API

A revoir

• Pour faire des groupes d'évènements : labels ? (Projet pédagogique : un garde fait plusieurs évènements avec une classe sur l'année)
• Basculer les Types en Catégories
• Créer une liste 1-N de Types (décorelés de Catégorie) + breaking change
• Tout est renommé
• Attention aux parsers
• Public visé : convertir les valeurs actuelles en liste (fonctionnalité de fusion ?)
• Organisateur >> Basculer de texte à Liste (n-n), attention aux migrations de données, attention aux parsers breaking change
• Un champ information privé (texte) /contact de l'intervenant ?

Autres

• Les catégories d'Events remontent dans APIv2 dès que des Event sont publiés pour cette catégorie, mais il faudrait que ce soit le cas uniquement pour des Event dont les dates ne sont pas passées (ou bien faire un mécanisme de dépublication des Event passés ?

• Le chapeau doit avoir une limite de charactère plus courte que celle en oeuvre sur tout le reste et dépendante du module (comment faire la configuration ?)

(pour les listes penser à faire des fixtures / attention à pas de supression en cascade pour les nouvelles listes)

Rétrocompatibilité

Pour les 2 champs renommés, on a choisi de continuer à les renvoyer dans l'API V2 avec leur nouveau nom, mais aussi leur ancien nom (01ebb8f), en indiquant bien dans l'API de ne plus utiliser les anciens noms, qui seront prochainement supprimés (https://github.com/GeotrekCE/Geotrek-admin/pull/3256/files#diff-a085f726206a57dfbedd6482cdb5bf24e03e86dd6b56fd01964dd673ed9b120dR455)

Migration des champs dont le type a changé

Pour la renommage du champs "participant_number" (text) en "capacity" (integer), lors de la migration, si le champs contient qu'un numérique, on le garde dans le champs, mais si il contient aussi du texte, on le bascule dans le champs "Infos pratiques", en le préfixant de "Participant :" : be18e7f#diff-a905699c6c53624377b204a209c6299cd83a562dd8be0ab109c935ca66e0f532R10
Idem quand on utilise un parser qui essaie d'insérer du texte dans "capacity" (5f4157f#diff-71ac8d9e1fee50fb9833c882caf7fdd44bb5e5cd6b34aba000223338b86a1315R8)

[camillemonchicourt]

Une grosse première partie a été développée et intégrée dans la version 2.88.0 (https://github.com/GeotrekCE/Geotrek-admin/releases/tag/2.88.0) :

• Ajout des champs end_time, cancelled, cancellation_reason, bookable et place au niveau des événements touristiques
• Le nouveau champs champs "Lieu d'événement" permet d'associer un événement à un lieu et de l'y localiser automatiquement (Ajouter des lieux aux événements touristiques #3266)
• Le champs cancellation_reason (liste) n'est affiché que si le champs cancelled (booléen Oui/Non) est coché
• Le champs booking (texte) n'est affiché que si le champ bookable (booléen Oui/Non) est coché
• Ajout d'un onglet "Évaluation" permettant actuellement de renseigner le nombre de participants par classe d'âge
  
• Correction de l'API qui ne renvoyait pas les événements sans date de fin ([API v2] Les événements sans date de fin ne sont pas présents dans les résultats de l'API #3127)
• Vérification que la date de fin est supérieure ou égale à la date de début
• Date de début obligatoire
• Réorganisation des champs dans le formulaire et la fiche détail
• Mise à jour de la vue v_touristicevents pour répercuter les ajouts et modifications de champs

Attention

• Le champs meeting_time a été renommé en start_time. Pour la rétrocompatibilité, les 2 intitulés sont renvoyés dans l'API
• Le champs participant_number a été renommé capacity et passé en format ENTIER au lieu de TEXTE. Pour la rétrocompatibilité, les 2 intitulés sont renvoyés dans l'API
• Si vous aviez des parsers d'imports spécifiques alimentant les événements touristiques, vous devez appliquer ces modifications de nom et format de champs.

[camillemonchicourt]

Les champs "Temps de préparation" et "Temps d'intervention" ont été ajoutés dans l'onglet "Évaluation" dans la version 2.89.0 (#3281) :

[camillemonchicourt]

La deuxième partie est discutée dans un autre ticket - #3587