Permissions : formulaire de demande de permissions

[bouttier]

Il est souhaité l’ajout d’un formulaire permettant aux utilisateurs de demander l’accès à certaines données sur une période donnée (https://github.com/PnX-SI/GeoNature/issues/3097). Cette fonctionnalité permet notamment aux bureaux d’études de demander l’accès aux données sensibles pour la durée de leur étude sur le périmètre géographique de cette dernière.

Cette fonctionnalité a été implémenté dans la branche feat/sinp (https://github.com/PnX-SI/GeoNature/issues/1062) et nécessite d’être adapté au modèle de données des permissions de GeoNature 2.13 pour être intégré.

On réduira les modifications du cœur de GeoNature au stricte minimum. Le formulaire de demande de permissions ainsi que l’interface de validation de ces dernières seront amené par un module externe.

On rajoutera à la table gn_permissions.t_permissions les colonnes suivantes :

• created_on : datetime, default = NOW()
• validated : booléen NULL : NULL = demande en cours | FALSE = refusée | TRUE = acceptée, default = TRUE
• validated_on : datetime, default = NOW()
• validated_by : FK id_role

Le module d’admin des permissions devra compléter validated_by avec le rôle courant. Ainsi, les permissions créées directement par les admins seront valides (valeur par défaut), et validated_by contiendra le rôle de l’admin ayant créé la permission.

La fonction _get_user_permissions sera modifier pour récupérer uniquement les permissions avec validated = TRUE. Les permissions NULL et FALSE sont ignorées.

Le module externe de demande de permission aura deux composant :

• création des demandes : un module front + une route backend permettant la création des permissions en base
• administration des demandes : un module flask-admin

Les permissions créé depuis le formulaire de demande auront validated = NULL et validated_on = NULL. Le module d’administration aura pour charge de modifier validated, validated_on & validated_by.

L’interface d’administration pourra se baser sur les actions de flask-admin pour l’acceptation ou le rejet des demandes.

[bouttier]

Dans l’implémentation #1062 est demandé au demandeur de permission ses motivations à l’origine de sa demande ainsi qu’un description de l’étude lié à la demande. Ça commence à faire beaucoup d’informations spécifiques à la demande de permissions … Dans la mesure où ces informations ne relève pas du fonctionnel et sont totalement inutile au fonctionnement de GeoNature, je pense préférable d’insérer ces informations dans une nouvelle table t_permissions_requests contenant une FK 1-1 vers t_permissions. Cette table serait créé par une branche alembic dédiée au module externe de demande de permissions et pourra se voir rajouter d’autres colonnes suivant les besoins du formulaire de demande de permissions.

[jpm-cbna]

Ça commence à faire beaucoup d’informations spécifiques à la demande de permissions …

Oui, dans l'implémentation de la branche feat/sinp, ces informations complémentaires sont gérées via le mécanisme de champs additionnel configuration via des paramètres du fichier de config geonature_config.toml.

Il semble que cela serait bien de maintenir ce mécanisme car il est simple et très adaptable à la majorité des besoins utilisateurs. En outre, cela stocke toutes les données au format JSON dans un seul champ de la base. Ce qui est suffisant vis à vis des besoins d'analyse/exploitation de ces données.

[jpm-cbna]

@bouttier Par contre, comment gère t on la durée de validité d'une permission ?

Dans la branche feat/sinp, les permissions ont un champ end_date qui a une valeur NULL pour les permissions permanentes et une date et heure (timestamp) pour les permissions temporaires.

La requête récupérant les permissions d'un utilisateur se charge d'exclure toutes les permissions ayant une date non NULL et située dans le passé.

[jpm-cbna]

Les fonctionnalités complémentaires disponibles dans la branche feat/sinp liées au formulaire de demande et non listés ici sont:

• envoie de mails aux demandeurs lors d'une acceptation/refus
• possibilité d'indiquer la raison du refus
• possibilité d'ouvrir une page présentation d'une convention récapitulant les informations "spécifiques" préalablement saisie par l'utilisateur et demander de valider son acceptation via le clic sur un bouton
• envoie d'un email récapitulatif de la demande effectuée à l'utilisateur

Si la gestion du formulaire de demande passe par une module externe, je pense que ces fonctionnalités pourront être facilement ajoutées, non ?

Il devrait être envisageable de récupérer pas mal de code sur la branche feat/sinp.

[bouttier]

Pour la validité temporelle d’une permission, c’est dans https://github.com/PnX-SI/GeoNature/issues/3099 : idem que feat/sinp (j’ai juste suggéré expire_on pour le nom de la colonne).

Merci pour le récapitulatif des besoins !

Et je suis bien d’accord qu’il faudrait récupérer autant que possible le code du formulaire sur feat/sinp, d’autant que, hormis l’API qui sera susceptible d’évoluer, l’interface front comme tu l’avais faites n’a pas de raison d’être remise en cause et pourra être reprise telle quelle je pense.

Pour le champs JSON, je suis partagé entre rajouter la colonne à t_permissions, et quand même rajouter une table 1-1 pour les demandes de permissions comme évoqué précédemment, qui contiendrait alors des champs structurés ainsi que la colonne générique JSON (ou HSTORE ?) dont tu parles.