====== Permrequest - Module de gestion de demandes de permissions ======
===== Besoins =====
* Transférer [[fonctionnalites:geonature:developpements-prioritaires#gestion_des_demandes_de_permissions| les fonctionnalités existante dans la version GeoNature 2.10]] branche ''feat/sinp'' de gestion des demandes d'accès dans un module ''gn_module_permrequest'' compatible avec la dernière version de GeoNature (v2.17.0).
* L'utilisateur et le validateur doivent pouvoir modifier des demandes. L'utilisateur peut seulement modifier ses demandes
* Un utilisateur doit pouvoir consulter ses demandes.
===== Modules existants =====
* [[https://github.com/PnX-SI/gn_module_permrequests| Module Permrequest]]
* [[https://github.com/naturalsolutions/gn_module_permission_request/tree/develop| Module Permission Request]]
===== Améliorations du code=====
* Renommer le schéma ''pr_permrequest''
* Refactoriser les constantes dans les migrations Alembic
* Gérer les dépendances et les configs d'outils dans pyproject.toml
* Réordonner les colonnes de la table ''t_permission_request''
* Renommer la table ''t_permission_request'' en ''t_requests'' et la garder dans le schéma ''pr_permrequests''
* Régler le problème d'activation directe des permissions lors de la création de la demande
* Ajouter le champ ''extras'' (json) ou ''additional_data'' (plus standard dans la base GN) dans la table ''t_requests'' du schéma ''pr_permrequests'' : il servira à stocker les valeurs du formulaire dynamique.
===== À faire =====
* Corriger le template par défaut de la notification DB PERMISSION_REQUEST_VALIDATION_UPDATE
* Gérer plusieurs permissions par demande : Lecture & Export
* Rendre non obligatoire la sélection d'un taxon
* Gérer les modifications d'une demande de permissions par l'utilisateur : nous avions pensé à bloquer la modification d'une demande par l'utilisateur après la validation par un admin. L'implémentation actuelle permet la modification par l'utilisateur mais la demande doit être à nouveau validée.
* Ajouter un paramètre de config pour masquer la séléction d'une demande de données sensible : avec le passage en OpenData des 2 SINP, la demande concerne forcément des données sensibles...
* A minima, corriger le problème d'affichage des noms des taxons quand on réaffiche la demande.
* Rendre visuel les champs obligatoire avec une astérisque rouge
* Ajouter un ou deux paramètres de config pour masquer la sélection de la portée et définir sa valeur par défaut
* Ajouter un paramètre de config pour définir la période par défaut de validité de la demande
* Ajouter un paramètre de config pour définir la durée max d'une demande
* Ajouter la gestion du formulaire dynamique au formulaire de demande
* Stocker seulement des cd_ref pour les permissions : pour limiter les problèmes de permissions appliquées seulement sur des synonymes...
* Ajouter la possibilité de valider une charte après avoir fait la demande : la charte doit être basée sur un template modifiable par l'administrateur du GeoNature.
* Activer la traduction du calendrier en français
==== Améliorations ====
* Utiliser une modale Angular Material à la place de NgbModal
* Améliorer la sélection des taxons de la demande : devrait fonctionner comme pour les zones géo.
* Améliorer la sélection des zones géo : les zones géo devraient être triées par type.
* Améliorer la liste des demandes, les colonnes "zone geo." et "Taxo. grp." devraient affichées le nombre d'éléments et au survol via un tooltip les noms des zones ou taxons concernés
* Améliorer la liste des demandes, la colonne "Sensibilité" devrait afficher OUI et NON en majuscule et OUI en rouge.
* Améliorer la liste des demandes, la barre de pagination devrait afficher le mot "total" à côté du nombre total d'éléments.
===== À voir/À confirmer =====
* Comment gérer les modifications d'une demande de permissions par l'utilisateur ? : ne pas donner la permission de modification à l'utilisateur si la demande est validée.
* Est ce que l'on empêche un utilisateur de supprimer sa demande de permissions ? : non, il peut supprimer. Mais il faudrait afficher une modale de confirmation.
* Actuellement 1 seule permission est créée par demande : c'est l'action R (lecture) mais il faudrait également créer une permission sur l'action E (Export) ? => Résolu dans la v0.4.0 avec la possibilité de configurer les permissions à créer pour une demande.
* Est qu'on peut simplifier les migrations Alembic ? : renommer/refactoriser les migrations par thème : ''initialize_schema'', ''add_permissions'', ''add_notifications'', ''add_samples''. => OK mais nécessitera un script SQL de migration spécifique pour l'installation de NS.