Filtre des JDD par les acteurs des CA

[TheoLechemia]

Les JDD accessibles (en lecture et en écriture) sont calculés à partir de la fonction filter_by_scope (https://github.com/PnX-SI/GeoNature/blob/master/backend/geonature/core/gn_meta/models.py#L262), qui vérifie les acteurs associés au JDD et également les acteurs définit au niveau du CA du JDD. Il a été remonté que les utilisateurs avait accès à "trop" de JDD à la saisie : en effet dès l'instant qu'un organisme est associé à un CA, alors l'utilisateur peut saisir dans tous les JDD associés (ce qui n'est pas toujours souhaitable). Est-ce qu'il faut conserver cet "héritage" des droits entre les CA et les JDD ?

[jbrieuclp]

Je l'avais déjà évoqué un moment, mais je persiste à penser qu'il est nécessaire de décorréler le droit d'accès spécifique à geonature des informations descriptives des métadonnées (les roles associés).

Il faudrait qu'au niveau des JDD (ou des CA) on puisse d'un côté décrire les acteurs et en parallèle à cette info pouvoir gérer les droits d'accès propre à l'appli.

Potentiellement 2 propositions en ce sens :

• Dupliquer les tables rôles des JDD et CA : ce qui est actuellement en place est ok pour gérer les accès geonature gardons ça comme ça, mais faisons en sorte que l'interface au niveau des JDD (et CA) soit dans une partie administration des accès. Pour ces tables jdd_actor_geonature le type de role (fournisseur, maitre d'oeuvre, ouvrage...) n'a plus lieu d'être, mais peut-être que l'info pourrait être remplacée par le type d'accès ouvert (le CRUD) Il faudrait donc créer de nouvelles tables jdd_actors et ca_actors pour gérer les vrais rôles, ceux qui sont nécessaires à la description des métadonnées, mais qui n'ont rien à avoir avec la gestion des droits d'accès de geonature.

• peut-être plus simple, mais plus bordélique et qui nécessite de revoir les fonctions scope de geonature, ajouter un booléen au table jdd_actor (et ca_actor) pour spécifier le droit d'accès (CRUD) associé à l'acteur renseigné. Mais si un acteur est renseigné plusieurs fois pour un JDD (producteur et maitre d'ouvre et fournisseur) le CRUD se retrouve répété en pouvant être différent.

En tout cas en séparant la description des métadonnées et la gestion des droits d'accès geonature il devient possible d'ouvrir en lecture des JDD à des organismes ou personnes tierces qui ne jouent aucun rôle dans le JDD ou CA et il deviendrait possible de gérer l'accès en lecture écriture au cas par cas par JDD/CA

[DonovanMaillard]

Présenté de cette manière en interface ça ne me semble pas forcement optimal, mais en soit je serais plutôt d'avis à distinguer les acteurs des métadonnées et les permissions comme tu le proposes, plutôt que limiter le type de rôle comme évoqué par Théo dans l'autre ticket.

A voir pour que ça ne soit pas trop usine à gaz non plus... la logique "mon organisme", "moi","tout" perdrait alors peut-être de son sens, car les droits seraient plus logiques à donner par groupes d'utilisateurs que par organisme ...

[camillemonchicourt]

Ce qu'évoque @TheoLechemia est que depuis peu (la 2.12 à priori avec le travail de fond sur les permissions), la liste des JDD listés quand on fait une observation dans Occtax (ou Occhab je pense que c'est pareil), regarde les acteurs des JDD et des CA (et non plus seulement ceux des JDD) pour appliquer les portées. Ce n'était pas le cas avant la 2.12, donc en mettant à jour GeoNature, certains se sont retrouvés avec la possibilité d'associer des relevés à des JDD non souhaités.

Pour illustrer :

Désormais si un utilisateur a un CRUVED C de portée 2 dans Occtax, quand il va vouloir associer un JDD à un relevé, il verra les JDD :

• Où lui ou son organisme sont acteurs
• Dont lui ou son organisme est acteur du CA (même si pas acteur du JDD)

C'est ça qui est nouveau et pas forcément souhaitable ni identifié.

[DonovanMaillard]

Oui en effet, pas souhaitable car justement la distinction CA/JDD pouvait être utilisée pour ça au niveau des droits...

[camillemonchicourt]

Pour le sujet plus global (à traiter ailleurs je pense), les permissions dans GeoNature sont complexes car on veut faire beaucoup de choses par rapport à ce qu'il se fait habituellement dans les outils, et car il y a des choses tordues dans notre domaine, comme la sensibilité, le floutage, les observateurs, etc...

Donc on ne se limite malheureusement pas, comme ailleurs, à définir des objets et dire qui peut les CRUD. On a des données, des JDD, des observateurs, des acteurs... Et on définit ça de manière croisée, à différents niveaux, avec parfois de l'héritage pour gérer des choses globalement, pas d'autres. 🤯

A mon avis, il ne faut pas encore compliqué ça en dupliquant et complexifiant la gestion des acteurs.

[DonovanMaillard]

Non non le but est pas de compliquer, à l'inverse. Je trouve ça bien assez compliqué voire trop, le but serait bien de chercher un fonctionnement plus simple et surtout plus clair pour tout le monde : admin et utilisateurs.

Le fonctionnement actuel fait qu'on doit des fois aller modifier les métadonnées ou les faire de manière hétérogène pour répondre à des besoins de permissions (rajouter une personne sur un JDD car il doit y avoir accès, alors que tous les autres utilisateurs ne sont pas mentionnés personnellement par exemple).

Le but serait de trouver une manière de décorréler métadonnées et permissions, qui sont deux notions différentes et pour lesquelles on peut en arriver à déformer les métadonnées dans certains cas... C'est pas un petit chantier....

[camillemonchicourt]

Oui dans la v2 de GeoNature on a voulu baser les organismes et les permissions associées en s'appuyant sur les JDD, car c'était très limité et lourd de gérer ça uniquement au niveau des observations elles-mêmes.

Cela a de nombreux avantages, mais aussi certaines contraintes.

Pour moi si on revoit ça (dans une V3 ?), alors il faudra simplifier et faire des choses plus classiques et basiques comme on trouve habituellement dans les outils.

[eloisemtPNFor]

Le fait que ce soit la structure actrice du CA qui prend le dessus sur les organismes acteurs des JDD n'aide pas non plus pour les exports depuis la synthèse.

Lorsque la restriction "Les données de mon organisme" est mise au niveau des droits d'exports et que l'utilisateur souhaite exporter des données d'un jdd de son organisme, et que l'organisme du CA est le sien l'utilisateur peut télécharger toutes les données (alors qu'il ne devrait pas pouvoir avoir accès aux données des autres structures).

[jpanijel]

Bonjour à tous, je me permets de donner la position de la plateforme nationale du SINP sur l'implémentation des permissions et de leur impact sur l'accès aux métadonnées et aux données. L'application des permissions depuis la V2.12 de GN, notamment l'héritage" des droits entre les CA et les JDD, nous paraît la solution la plus cohérente pour l'instant. Sur le plan juridique et moral, il nous paraît indispensable que les acteurs d'un CA (maître d'ouvrage, financeur, maitre d’œuvre...) puissent accéder aux données des JDD des CA qu'ils portent et qu'ils puissent exercer leurs responsabilités de contrôle et de supervision. Sur le plan fonctionnel, l'effet de bord pour les utilisateurs rattachés aux organismes en question, bien que gênant, nous semble passer en second plan.

[camillemonchicourt]

Le sujet avait en fait été indiqué ici : https://github.com/PnX-SI/GeoNature/issues/2158. Et daterait de plus longtemps (2.9).