Saisie et CRUVED datasets / Organisme(s)

[jbrieuclp]

J'suis paumé ! Et l'issue est longue et en 3 parties !

J'ai créée un groupe où je voudrais que les personnes qui y soient aient accès à leurs données perso dans OCCTAX (en CRUD), accès en lecture seule à toutes les données dans METADATA et accès aux données de l'organisme dans SYNTHESE (en RE).
Pour avoir les modules de présents dans l'app je suis obligé de mettre au moins des droit à GEONATURE (en R sur mes données)

Avec ce schéma de conf ça fonctionne à la visualisation dans OCCTAX (je vois mes données) et SYNTHESE (je vois mes données + organisme) ok

Module METADATA c'est la zermi : je ne vois rien (ou seulement les métadonnées auxquelles je suis personnellement rattaché).
Le TODO ici explique un peu la cause du problème :

GeoNature/backend/geonature/core/gn_meta/routes.py

Lines 43 to 48 in bab3dba

	# TODO: quel cruved on recupère sur une route comme celle là
	# celui du module admin (meta) ou celui de geonature (route utilisé dans tous les modules...)
	@routes.route("/datasets", methods=["GET"])
	@permissions.check_cruved_scope("R", True)
	@json_resp
	def get_datasets(info_role):

Les données sont récupéré selon les droits du module GEONATURE (R = mes données).
Bon, en gros il suffit de passer le nom du module module_code=METADATA en 3eme paramètre pour régler l'affaire du module métadonnée @permissions.check_cruved_scope("R", True, module_code="METADATA")
MAIS, dans le module OCCTAX la liste des JDD sera peuplé par l'ensemble des JDD. Eurgh !
Du coup il faudrait avoir deux routes pour cette fonction : /datasets/occtax et /datasets/metadata (ou l'inverse : /occtax/datasets et /metadata/datasets) l'origine (occtax ou metadata) pourrait être récupéré pour être passé en 3eme paramètres comme indiqué plus haut.

Autre remarque :

GeoNature/backend/geonature/core/gn_meta/repositories.py

Lines 31 to 41 in bab3dba

	else:
	q = q.filter(
	or_(
	CorDatasetActor.id_organism == info_role.id_organisme,
	CorDatasetActor.id_role == info_role.id_role,
	)
	)
	elif info_role.value_filter == "1":
	q = q.join(
	CorDatasetActor, CorDatasetActor.id_dataset == TDatasets.id_dataset
	).filter(CorDatasetActor.id_role == info_role.id_role)

Ici on exploite pas l'organisme "ALL". En ajoutant cette clause SQL au OR on règle l'affaire :
CorDatasetActor.id_organism == 0, Il faut l'ajouter ET à l'accès données organisme et à l'accès données perso

Enfin, si jamais j'ai un copain a des droits d'écriture dans un JDD auquel il a accès mais pas moi, qu'il y créé une donnée ou je suis associé au relevé, je suis observateur donc j'aurais des droits de modif de cette donnée, par contre si je rentre dans le formulaire de modif, n'ayant pas accès au JDD, la valeur du JDD sera perdue !
Du coup là aussi c'est la zermi !

[TheoLechemia]

Sur le 1er problème, on en a déjà parlé ici (#552). Deux solutions:

• Dupliquer les routes. En sachant qu'on a déjà une fonction dans le "repository" qui permet de récuperer des JDD à partir du CRUVED, on ne duplique pas grand chose.
• Passer le "module_code" via paramètre GET . Mais du coup, c'est falsifiable. (Qui va allé changer l'url de l'api pour accéder en lecture à des JDD auxquels il n'a pas accès ?)

2ème problème:
pas pour utiliser l'organisme "ALL" comme filtre CRUVED. C'est d'ailleurs historique la présence de cet organisme. Je ne vois pas dans quel contexte il est utilisé ?

3ème problème:
bien vu. J'ai pas de solution qui me vient. Il faut voir comment gérer ça côté front, car techniquement l'id_dataset est bien présent. Je regarde...

[camillemonchicourt]

De mémoire aussi, tout le CRUVED n'est pas forcément implémenté à tous les niveaux dans tous les modules.
Par exemple, je ne suis pas sur qu'il y encore de comportement READ ONLY implémenté dans le module METADATA.

[jbrieuclp]

Sur le 1er problème, on en a déjà parlé ici (#552). Deux solutions:
Dupliquer les routes. En sachant qu'on a déjà une fonction dans le "repository" qui permet de récuperer des JDD à partir du CRUVED, on ne duplique pas grand chose.

Y peut-être tout simplement moyen d'avoir une fonction/route abstraite et 2 routes héritées qui surchargent avec des paramètres permissions.check_cruved_scope différents. J'sais pas si ça se fait avec Flask ça ?

Sur le 1er problème, on en a déjà parlé ici (#552). Deux solutions:
Passer le "module_code" via paramètre GET . Mais du coup, c'est falsifiable. (Qui va allé changer l'url de l'api pour accéder en lecture à des JDD auxquels il n'a pas accès ?)

Moi. Du coup même si dans ce contexte c'est pas zinzin comme truc, j'aime pas faire confiance aux utilisateurs...

2ème problème:
pas pour utiliser l'organisme "ALL" comme filtre CRUVED. C'est d'ailleurs historique la présence de cet organisme. Je ne vois pas dans quel contexte il est utilisé ?

Ouai, t'as raison, je confonds accès aux données et description des CA/JDD

3ème problème:
bien vu. J'ai pas de solution qui me vient. Il faut voir comment gérer ça côté front, car techniquement l'id_dataset est bien présent. Je regarde...

Pour ce cas, une solution/proposition serait de virer le champ si l'obs n'a pas de droits de saisie dans le JDD. La zone de liste pourrait être virée ou mieux, remplacée par la valeur chargée en texte simple.

[TheoLechemia]

Moi. Du coup même si dans ce contexte c'est pas zinzin comme truc, j'aime pas faire confiance aux utilisateurs...

Je suis d'accord avec toi, mais du coup si on duplique les routes, on aura :

• une route qui check le "R" sur GeoNature pour les besoin généraux (lesquels ?)
• une route qui check le "C" sur occtax pour la saisie occtax (et X routes par module de saisie)
• un route qui check le "R" de metadata pour le module métadonnées.

Donc quelqu'un qui est malin et qui veut avoir tous les JDD, il interroge la route qui lui donne le plus de droits ...

[TheoLechemia]

Mais si on offre la possibilité de changer l'action et le module au niveau du décorateur (via param GET), ça ouvre une grosse porte sur toutes les routes, et n'importe qui, qui a des droit élevé sur un module peut faire ce qu'il veut sur tous les autres...
Donc bof !

[bouttier]

Je serais plutôt pour faire une seule route, même si elle donne accès à un ensemble de datasets en fonction de plusieurs permissions différentes. Ceci afin d’éviter de multiplier les routes, et pour éviter d’éclater la gestion des permissions d’accès au datasets, sinon savoir à quel dataset a-t-on le droit d’accéder va être très compliqué à la lecture du code.

[TheoLechemia]

La PR #1526 solutionne ce problème :
On prend d'abord la liste des JDD sur-lesquels à des droits de lectures, puis on restreint éventuellement aux JDD auxquels l'utilisateur à des droits de création dans le module demandé. Cela se fait via la query string ?create=<module_code>
On ne pourra donc jamais "créer" dans un JDD sur lesquels on n'a pas les droits de lecture, et par la même "falsifier" ses droits via la querystring.

Ex dans le module Occtax : si OCCTAX C = 3 et GeoNature R = 2. L'utilisateur ne pourra saisir que dans les JDD équivalent à GeoNature R=2.
Si OCCTAX C = 1 et GeoNature R = 2 il pourra saisir uniquement sur ses JDD

[camillemonchicourt]

A partir de la 2.9.0, la liste des JDD proposée à l'utilisateur lors de la saisie dans un module est basé sur le C du CRUVED de l'utilisateur (ou du C du CRUVED sur GeoNature si l'utilisateur n'a pas de permissions définies sur le module).

Pour les autres sujets du ticket @jbrieuclp à ouvrir dans d'autres issues pour fermer celle-ci ?