Giter Club home page Giter Club logo

Comments (10)

camillemonchicourt avatar camillemonchicourt commented on September 25, 2024 1

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.

from geonature.

eloisemtPNFor avatar eloisemtPNFor commented on September 25, 2024 1

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

from geonature.

jbrieuclp avatar jbrieuclp commented on September 25, 2024

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.
    Image1
    Image2

  • 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

from geonature.

DonovanMaillard avatar DonovanMaillard commented on September 25, 2024

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

from geonature.

camillemonchicourt avatar camillemonchicourt commented on September 25, 2024

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

from geonature.

DonovanMaillard avatar DonovanMaillard commented on September 25, 2024

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

from geonature.

camillemonchicourt avatar camillemonchicourt commented on September 25, 2024

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.

from geonature.

DonovanMaillard avatar DonovanMaillard commented on September 25, 2024

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

from geonature.

jpanijel avatar jpanijel commented on September 25, 2024

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.

from geonature.

camillemonchicourt avatar camillemonchicourt commented on September 25, 2024

Le sujet avait en fait été indiqué ici : #2158.
Et daterait de plus longtemps (2.9).

from geonature.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.