Exploitation.md

Variabilisation et modifications possibles pré-instalation

Catégories et applications affichés dans le portail

Pour modifier les catégories affichées dans le portail il faut modifier la variable vitamui_default.portal_categories dans deployment/environnement/group_vars/all/vitamui_vars.yml. Cette variable modifie également l'affichage de la popin de changement d'application accessible depuis le bandeau supérieur.

Cette variable doit être formée comme suit:

portal_categories:
    <id_category_1>:
      title: "<titre_category_1"
      displayTitle: <boolean>
      order: <integer>
    <id_category_2>:
      title: "<titre_category_2>"
      displayTitle: <boolean>
      order: <integer>

avec pour valeurs:

• id_category_x: L'id de la catégorie à créer. Elle doit correspondre au champ category pour les applications dans la base mongo.
• titre_category_x: est une chaîne de caractères qui définit ce qui sera affiché comme titre dans l'IHM.
• displayTitle: définit si le titre de cette catégorie doit être affiché ou non. Certaines catégories (comme pour celle contenant l'application "Mon Compte") n'affichent pas leurs titres.
• order: Définit l'ordre d'affichage des catégories dans l'IHM (ordre croissant).

Si une des applications de la base Mongo renseigne une catégorie qui n'existe pas dans cette liste, elle sera affichée dans une catégorie "Par défaut" tout en bas de la liste des catégories.

Pour le suivi, cette configuration est ensuite déployé dans tous les services UI de Vitam-UI sous le chemin: /vitamui/conf/ui-xxx/application.yml

Droits par défaut lors de la création d'une organisation

Pour modifier les droits par défaut associés aux organisations, il est possible de modifier le fichier customer_init.yml présent dans deployment/roles/vitamui/files. Pour le moment, aucune variable n'a été définie dans l'ansiblerie, et ce fichier est à modifier directement au besoin.

Ce fichier est formé de la manière suivante:

customer-init:
  profiles:
    - name: <customerProfileName>
      description: <customerProfileDescription>
      level: <integer>
      app-name: <applicationName>
      roles:
        - <role_1>
        - <role_2>
        - ...
  profiles-groups:
  - name: <groupName>
    description: <groupDescription>
    level: <integer>
    profiles:
      - <profileName_1>
      - <profileName_2>
      - ...
  users:
    - last-name: <lastName>
      first-name: <firstName>
      profiles-group-name: <groupName>
      level: <integer>
      email-prefix: <emailPrefixBeforeAt>
  tenant-profiles:
    - name: <tenantProfileName>
      description: <tenantProfileDescription>
      level: <integer>
      app-name: <applicationName>
      roles:
       - <role_1>
       - <role_2>
       - ...
  admin-profiles:
    - name: <adminProfileName>
      description: <adminProfileDescription>
      app-name: <applicationName>
      level: <integer>
      roles:
        - <role_1>
        - <role_2>
        - ...

Dans cette liste de valeurs, toute les listes de profils (profiles, tenant-profiles, admin-profiles) ont la même structure qui est la suivante:

• name: correspond au nom du profil, qui sera affiché dans l'IHM et qui sert d'identifiant de profile pour les groupes de profils.
• descrpition: une description du profil
• level: Niveau de droits auquel le profil appartient. Peut être laissé vide pour un niveau minimal.
• app-name: champ identifier de l'application pour laquelle on ajoute un droit
• roles: liste des rôles accordés grâce à ce profil

Les différentes listes de profils sont:

• profiles: Profils créés et associés à toutes nouvelles organisations créées.
• admin-profiles: Profils accessibles à tout administrateur de nouvelles organisations.
  • Un groupe spécifique "ADMIN_CLIENT_ROOT" est créé contenant entre autres cette liste de profils.
  • Cette catégorie est spécifique aux applications ayant le même comportement sur plusieurs tenants. Par exemple, si vous voulez donner accès en lacture au référentiel des formats de fichier.
• tenant-profiles: Profil créé et associé à tout nouveau tenant créé (y compris le tenant de preuve de l'organisation).
  • Les profils de cette liste irons aussi dans le groupe "ADMIN_CLIENT_ROOT" mais il sera créé autant de profile que l'organisation à de tenants.
  • Cette catégorie est spécifique aux applications ayant un comportement différent en fonction du tenant. Par exemple, l'application de gestion des entrées.

En plus des profils il est possible de spécifier des groupes de profils grâce à profiles-groups. La structure est la suivante:

• name: Correspond au nom du groupe, qui sera affiché dans l'IHM et sert d'identifiant pour être rattaché à un utilisateur.
• description: Une description du groupe de profils
• level: Niveau de droits auquel le groupe de profil peut avoir accès. Peut être vide pour un niveau maximal.
• profiles: Liste des profiles dont les applications seront accessibles via ce profil. Le champ "name" des profils est à renseigner

Enfin, il est également possible de renseigner des utilisateurs qui seront automatiquement créés à chaque nouvelle organisation créée grâce à users:

• last-name: Nom de famille de l'utilisateur à créer
• first-name: Prénom de l'utilisateur à créer
• profiles-group-name: Groupe de profils à associer à l'utilisateur pour lui accorder les droits associés
• email-prefix: Partie locale de l'adresse mail (précédent le @). Le domaine étant directement associé à l'organisation.

Pour le suivi, ce fichier est ensuite déployé dans le service IAM internam de Vitam-UI sous le chemain: /vitamui/conf/iam-internal/customer-init.yml

Exemple de configuration

Pour l'exemple, on veut une configuration permettant:

• de visualiser (lecture seule) les formats de fichiers => PROFIL_FILE_FORMAT_ADMIN
• de visualiser les entrées et lancer une nouvelle entrée de SIP => PROFIL_INGEST_TENANT
• de créer un utilisateur Jonathan Joestar dans chaque organisation créée (ayant comme addresse jo.jo@<customer_domain>) => users
  • Cet utilisateur devra pouvoir accéder aux dépôt et suivi des versements en lecture seule => PROFILE_INGEST_READONLY / GROUP_INGEST_READONLY

Pour cela le fichier d'initialisation des organisations contiendra:

customer-init:
  profiles:
  - name: PROFILE_INGEST_READONLY
    description: Profil d'access en lecture seule sur le dépot et suivi des versements
    level:
    app-name: INGEST_APP
    roles:
      - ROLE_GET_ALL_INGEST
      - ROLE_GET_INGEST
  profiles-groups:
  - name: GROUP_INGEST_READONLY
     description: Groupe d'access en lecture seule sur le dépot et suivi des versements
     level:
     profiles:
       - PROFILE_INGEST_READONLY
  users:
  - last-name: Joestar
    first-name: Jonathan
    profiles-group-name: GROUP_INGEST_READONLY
    level:
    email-prefix: jo.jo
  tenant-profiles:
    - name: PROFIL_INGEST_TENANT
      description: Gestion des application de dépot et suivi des versements
      app-name: INGEST_APP
      level:
      roles:
        - ROLE_GET_INGEST
        - ROLE_CREATE_INGEST
        - ROLE_GET_ALL_INGEST
  admin-profiles:
  - name: PROFIL_FILE_FORMAT_ADMIN
    description: Accès en lecture sur les formats de fichiers
    level:
    app-name: FILE_FORMATS_APP
    roles:
     - ROLE_GET_FILE_FORMATS