Réintégration du CRUVED dans GeoNature

[camillemonchicourt]

L'année dernière, une réflexion sur les besoins en matière de gestion de droits avait abouti à la mise en place du CRUVED : #238

Dans UsersHub V1, il n'y avait que 6 niveaux de droits attribuables aux utilisateurs par application. Cela s'était montré trop contraint, notamment dans GeoNature.

Le CRUVED permet des droits bien plus fins que les 6 niveaux de droits d'une application. Il permet de définir des actions sur des portées par module de GeoNature.

En intégrant un système générique de TAGS dans UsersHub depuis sa version 1.3.1, on a pensé pouvoir gérer le CRUVED de GeoNature de manière générique dans UsersHub.

Alors que nous finalisons la version 2.0.0 de UsersHub, que l'usage des tags et du CRUVED a commencé à être utilisé, on se rend compte que :

• le CRUVED est une logique spécifique à GeoNature
• le CRUVED est bien fonctionnel pour gérer les droits dans les modules de GeoNature mais pas suffisant pour d'autres besoins liés aux droits dans GeoNature.

Du coup, la conclusion est de réintégrer le CRUVED dans la BDD (et l'interface) de GeoNature. A voir où on stocke. Dans gn_commons ou dans un schéma dédié gn_users comme on l'avait fait au début.

Plus largement, cela permettra de :

• Réduire la dépendance de GN à UH
• Retirer les aspects spécifiques à GN de UH
• Faciliter la mise en place d'autres droits spécifiques à GN en ne l'imposant pas dans UH (droits sur les métadonnées, les nomenclatures..., accès aux données précises ou floutées, gérer les visites mais pas les sites de suivi...)
• De mettre donc en place en complément des droits sur des objets au sein de GN (Admin métadonnées, Admin sites de suivi....) comme on le fait déjà avec la table gn_export.cor_role_export
• Recentrer UH sur ce pourquoi il est fait (gérer des utilisateurs, login, mot de passe, des groupes, des accès à des applications et éventuellement des tags et listes d'utilisateurs)
• Rester au maximum dans une logique de Gestion d'utilisateurs classique dans UsersHub pour permettre de le remplacer par des mécanismes plus standards (LDAP, CAS, Oauth...)
• Ne plus avoir à ajouter les modules de GeoNature dans les applications de UsersHub

A voir, comment on gère l'accès à GeoNature et son CRUVED car ce n'est pas un module. Pour son accès, avoir une autorisation classique comme les autres applications et niveau de UH et ensuite gérer la surcouche CRUVED (et éventuellement autre) côté GeoNature ?

A voir aussi sur quoi on se base pour lister les rôles dans GeoNature à qui on peut appliquer un CRUVED de GeoNature (uniquement ceux qui ont accès à GeoNature ?)

Gros chantier :

• En BDD et en migration de données
• Retirer les routes et fonctions du CRUVED du sous-module d'authentification de UsersHub pour les intégrer dans GeoNature
• Revoir la procédure d'installation d'un module et son usage du id_application
• Appliquer les modifications sur les modules GeoNature existants ?

Côté UsersHub, d'autres questions annexes mais structurantes sont posées aussi :

• Groupes et tags redondants ?
• Gérer les listes (d'observateurs notamment) dans une table t_listes ou un type de tags comme prévu actuellement ?

[camillemonchicourt]

Ce travail est confirmé et en même temps la logique du CRUVED va être élargie au sein de GeoNature.

Avec la création d'un schéma gn_permissions contenant notamment une table de correspondance permettant de stocker les CRUVED élargis à :

• id_role
• id_action
• id_filter (portée, territoire, rang taxo, précisions...)
• id_module
• id_object (optionnel)

[DonovanMaillard]

Donc le cruved permettra à lui seul de lire les données précises ou floutees (à voir comment on articulé ça avec la sensibilité dans notre cas), la possibilité de valider uniquement un ordre donné, etc ? Top tout ça !!

[camillemonchicourt]

Ça pourra le permettre.

[DonovanMaillard]

Yep ji bien compris que la ça reste binaire : on lit ou non. On devra faire l'étape "on lit MAIS pas précis ;)merci en tous cas pour tout ca

[camillemonchicourt]

Par contre si on veut que le filtre limite les données à un territoire géographique ou à un rang taxonomique, alors il faut pouvoir stocker des id_area ou des cd_nom dans le champs id_filter de la table gn_permissions.cor_role_action_filter_module_object.

Hors ce champs a une clé étrangère vers gn_permissions.t_filters. C'est normal et souhaitable mais faut-il casser cette clé étrangère pour permettre un mode mixte et permissif de contenu des filtres en fonction de leur type (gn_permissions.bib_filters_type), ou plutôt gérer les CRUVED géographiques et taxonomiques dans une autre table ?

[camillemonchicourt]

Après discussion, on garde la table gn_permissions.t_filters en permettant d'y mettre des id_area ou des cd_nom (valeur unique ou ensemble de valeurs) selon le type de filtre.

[camillemonchicourt]

Le mécanisme est implémenté : #529

Et une interface de gestion a été développée dans le module ADMIN :

[camillemonchicourt]

Fait dans la 2.0.0-rc.4