Dissocier les droits applicatifs des groupes Sugoi

[EmmanuelDemey]

Cette carte vise à mettre en œuvre le résultat des ateliers du séminaire RMéS de juin 2023 sur la gestion des droits. L'objectif est de dissocier les droits appliqués dans l'application Bauhaus des groupes Sugoi (ie de ne plus avoir les groupes dans le code de l'application) afin de rendre possible d'autres organisation du travail pour les utilisateurs de Bauhaus sans changer le code de l'application.

Le principe de base serait de paramétrer quelque part (dans un fichier de configuration probablement) les droits associés aux groupes Sugoi et par ailleurs de gérer les droits dans l'application suivant des fonctionnalités de base : créer (C), lire (R), modifier (U), supprimer (D), et aussi publier (P) voire valider (V) [actuellement il n'y a pas de différence entre publier et valider]

Pour chaque action de l'utilisateur, le contrôle d'autorisation serait fonction des droits de l'utilisateurs, calculés à partir de son appartenance à différents groupes et des droits indiqués dans le fichier de paramètre pour ces groupes. Par exemple, pour créer un concept, l'utilisateur devrait appartenir à un groupe autorisé à créer (C) un concept.

La description des droits associés à un groupe Sugoi est une matrice avec en ligne les différents types d'objets (concepts, séries, opérations, nomenclatures...) et en colonne les différents droits (créer, lire, modifier...), Chaque élément de la matrice peut prendre trois valeurs : "autorisé sans restriction", "autorisé selon le timbre de l'utilisateur" et "non autorisé". Les droits de l'utilisateurs correspondent à la matrice contenant le droit le plus élevé de tous les groupes auxquels il appartient.

La forme du fichier de paramétrage est à définir mais il pourrait être un fichier json, ne contenant pas les "non autorisés" (qui n'ont pas d'intérêt). Par exemple en reprenant de façon simplifiés quelques groupes actuels (et en se restreignant aux modules concepts et opérations), il pourrait ressembler à :

{
    "Administrateur_RMESGNCS": {
        "concept": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "collection": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "family": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "serie": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "operation": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "indicator": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "sims": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
        "classification": {"create": "A", "read": "A", "update": "A", "delete": "A", "publish": "A", "validate": "A"}
    },
    "Utilisateur_RMESGNCS": {
        "concept": {"read": "A"}
        "collection": {"read": "A"}
        "family": {"read": "A"}
        "serie": {"read": "A"}
        "operation": {"read": "A"}
        "indicator": {"read": "A"}
        "sims": {"read": "A"}
        "classification": {"read": "A"}
    },
    "Gestionnaire_concept_RMESGNCS": {
        "concept": {"create": "B", "read": "B", "update": "B", "publish": "B", "validate": "B"}
    },
    "Gestionnaire_ensemble_concepts_RMESGNCS": {
        "concept": {"create": "A", "read": "A", "update": "A", "publish": "A", "validate": "A"}
    },
    "Gestionnaire_serie_RMESGNCS": {
        "serie": {"read": "B", "update": "B", "publish": "B", "validate": "B"}
        "operation": {"create": "B", "read": "B", "update": "B", "publish": "B", "validate": "B"}
        "sims": {"create": "B", "read": "B", "update": "B", "publish": "B", "validate": "B"}
    },
    "Gestionnaire_indicateur_RMESGNCS": {
        "serie": {"read": "B", "update": "B", "publish": "B", "validate": "B"}
        "indicator": {"create": "B", "read": "B", "update": "B", "publish": "B", "validate": "B"}
        "sims": {"create": "B", "read": "B", "update": "B", "publish": "B", "validate": "B"}
    },
}

(toutes les valeurs sont à débattre, en particulier A et B pour les deux niveaux d'autorisation, tenant compte ou non du timbre de l'utilisateur)

Cette modification est probablement assez importante en volume. Il est possible de la découper en plusieurs cartes. Par exemple en commençant par gérer le fichier de paramétrage, puis le calcul des droits de l'utilisateurs, puis en prenant en compte petit à petit ces droits dans les différents modules.

[EmmanuelDemey]

@EmmanuelDemey va découper cela

[EmmanuelDemey]

• [ ] Définir le modèle de donnée (pour pouvoir gérer les différentes possibilité A, B, ...) et définir la classe Java nécessaire
• [ ] Initier un fichier yml dans le projet afin de représenter ces informations
• [ ] Coté back, implémenter un service qui permet, à partir d'un role, retourne les droits agrégés
• [ ] Implémenter le nouveau mécanisme pour le module DataSet coté Back
  • [ ] S'assurer qu'un test existe afin de vérifier la non regression
• [ ] Retourné les droits au front
• [ ] Implémenter coté front pour le module DataSet
  • [ ] S'assurer qu'un test existe afin de vérifier la non regression
• [ ] Si tests concluant, généraliser
  • [ ] Module Concept
  • [ ] Module Nomenclature
  • [ ] Module Operation
  • [ ] Module Structure
  • [ ] Module CodeList

[davdarras]

wrong project ? :)

[EmmanuelDemey]

INDEED @davdarras