[Permissions] Suppression de l'héritage des permissions pour les modules et les objets

[VincentCauchois]

Contexte

Actuellement, la récupération de la liste des permissions pour un tuple (action_code, id_role, module_code, object_code) se fait dans la fonction _get_permissions, avec un mécanisme d'héritage des permissions du module "GEONATURE" et/ou de l'objet "ALL", lorsque aucune permission n'est définie pour le module module_code et/ou l'objet object_code. Ainsi :

• Si aucune permission n'est trouvée pour l'objet object_code c'est une permission pour l'objet "ALL" qui est cherchée.
• Si aucune permission n'est trouvée pour le module module_code, alors c'est une permission pour le module "GEONATURE" qui est cherchée,

Ce mécanisme, pour être effectif, s'accompagne d'une écriture de permissions minimales pour le module "GEONATURE" et l'objet "ALL", lors de la création de la BDD d'une instance GeoNature. Il s'agit ensuite d'ajouter des permissions spécifiques, au besoin, pour les autres modules et autres objets.

Si cela offre le double avantage de ne pas avoir à écrire de permission dans un premier temps ainsi que de ne pas avoir à spécifier les permissions pour chaque module et chaque objet, on a dans les faits une difficulté pour déterminer comment sont héritées les permissions et un manque de lisibilité pour un administrateur GeoNature.

Dans le cadre de la refonte des permissions, on souhaite supprimer ce mécanisme d'héritage des permissions, et contraindre l'administrateur à configurer les permissions désirées pour les autres modules que "GEONATURE" et pour les autres objets que "ALL".

Proposition

Le mécanisme d'héritage des permissions du module "GEONATURE" et "ALL" est retiré dans la fonction _get_permissions. Si on souhaite obtenir une permission pour un module autre et/ou un objet autre, alors que celle-ci n'est pas directement présente dans la table cor_role_action_filter_module_object, alors une liste vide est renvoyée.

Afin de calculer les mêmes permissions avant et après suppression de cet héritage, une migration Alembic est ajoutée afin de peupler la table gn_permissions.cor_role_action_filter_module_object. Sont ainsi ajoutées, en dur, les permissions qui étaient héritées au calcul :

• Pour l'héritage du module GEONATURE, on regarde toutes les permissions (role, action, filter, "GEONATURE", object) de cor_role_action_filter_module_object. Pour chaque autre module ; en lisant la table gn_commons.t_modules ; on inscrit la permission (role, action, filter, other_module, object) sauf s'il existe déjà une entrée (role, action, _ , other_module, object), et ce quelle que soit la valeur de filtre de cette dernière permission.
• Pour l'héritage de l'objet ALL, on regarde toutes les permissions (role, action, filter, module, "ALL"). Pour chaque autre objet ; en lisant la table gn_permissions.t_objects associé au module en question ; d'après la table gn_permissions.cor_object_module ; on inscrit la permission (role, action, filter, module, other_object) sauf s'il existe déjà une entrée (role, action, _ , module, other_object), et ce quelle que soit la valeur de filter de cette dernière permission.

/!\ (héritage des permissions groupe -> utilisateur) :
Pour l'héritage des permissions (role_groupe, action, filter_groupe, module, object) associées à un role qui est un groupe, on vérifie s'il n'y pas un utilisateur associé à ce groupe et pour lequel on aurait une permission (role_utilisateur, action, filter_utilisateur, module, object) où filter_utilisateur < filter_groupe : c'est-à-dire une permission pour l'utilisateur qui correspondrait à une restriction de la permission définie pour le groupe. Dans ce cas, on n'ajoute pas la permission (role_groupe, action, filter_groupe, module, objet), et ce afin d'éviter que l'utilisateur se retrouve, après calcul avec héritage groupe>utilisateur, avec une permission (role_utilisateur, action, max(filter_groupe, filter_utilisateur), objet) trop importante. À la place, on reporte l'ajout de la permission à tous les autres utilisateurs associés au groupe.

TODO

• Suppression de l'héritage des permissions du module "GEONATURE" et de l'objet "ALL" dans la fonction _get_permissions
• Retrait du groupby par modules et objets dans la fonction _get_permissions + retrait du tri par module_code et par object_code dans la fonction _get_user_permissions
• Modifications en conséquence des tests unitaires du fichier "test_permissions.py"
• Création d'une migration Alembic pour :
  • Ajouter toutes les permissions nécessaires dans la table gn_permissions.cor_role_action_filter_module_object, pour garantir que les instances déjà déployées continuent à fonctionner comme avant :
    --> Héritage des permissions pour le module "GEONATURE" vers les autres modules
    --> Héritage des permissions pour l'objet "ALL" vers les autres objets lorsque l'association (module, objet) est bien présente dans cor_object_module.
    --> /!\ (exception A) On n'ajoute une permission (role, action, scope, module, object) que lorsqu'il n'y a pas déjà une permission (role, action, _ , module, object), et ce quel que soit le scope de cette dernière permission
    --> /!\ (exception B) On n'ajoute une permission (groupe_g0, action, scope_groupe_g0, module, object) que si le groupe n'a pas d'utilisateur associé pour lequel est définie une permission (utilisateur_u0, action, scope_utilisateur_u0, module, object) restrictive ; i.e. avec scope_utilisateur_u0 < scope_groupe_g0 ; alors, on n'inscrit pas cette permission pour le groupe. Cela évite que, au calcul des permissions avec héritage groupe_g0->utilisateur_u0, l'utilisateur u0 se retrouve avec une permission (utilisateur, action, scope_groupe, module, object), au lieu de (utilisateur, action, scope_utilisateur, module_object). Le cas échéant, on reporte l'ajout au niveau de chacun des autres utilisateurs associés au groupe g0 : et on ajoute une telle permission (utilisateur_uN, action, scope_groupe_g0, module, object) que lorsqu'il n'y a pas déjà une permission (utilisateur_uN, action, _ , module, object), et ce quel que soit le scope de cette dernière permission, par application de l'exception A.
  • Supprimer le SCOPE 0 (qui n'était utilisé que pour empêcher l'héritage d'un scope plus élevé) : table gn_permissions.t_filters
  • Supprimer les permissions avec SCOPE 0 de gn_permissions.cor_role_action_filter_module_object
• Mise à jour des commentaires dans le fichier [gn_permissions/tools.py](https://github.com/PnX-SI/GeoNature/blob/aeb2cd1939cb4d498ea575a02ac34a2d08494445/backend/geonature/core/gn_permissions/tools.py
• Mise à jour de la documentation sur la "gestion des droits" : https://docs.geonature.fr/admin-manual.html#gestion-des-droits

[camillemonchicourt]

OK, en effet la suppression de l'héritage des permissions avait déjà été évoquée et confirmée ici - #1622

Il est préféré avoir uniquement des permissions explicites, bien plus claires et lisibles.

[camillemonchicourt]

Il faudra aussi revoir cette documentation : https://docs.geonature.fr/admin-manual.html#gestion-des-droits

[camillemonchicourt]

L'héritage des permissions a été supprimé dans la version 2.13.0, et l'ensemble des permissions existantes ont été remises à plat dans une migration automatique.

Le seul effet de bord constaté est que désormais quand on installe une nouvelle instance de GeoNature, le groupe "En_poste" n'a pas de permissions sur les modules Occtax, Occhab et Validation.
C'est logique car il applique toutes les migrations Alembic. Et donc il applique les migrations de GeoNature (dont la remise à plat des permissions sans héritage) puis installe les modules.
Certainement à revoir, en remettant des permissions par défaut sur ces modules à ce groupe ?