Permissions : formulaire de demande de permissions about geonature HOT 5 OPEN

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.

from geonature.

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.

from geonature.

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

from geonature.

@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é.

from geonature.

Pour la validité temporelle d’une permission, c’est dans #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.

from geonature.