2. Variabilisation et modifications possibles pré-installation

2.1. 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

2.2. 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 lecture 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).
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 chemin: /vitamui/conf/iam-internal/customer-init.yml

2.2.1. 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 jojo@<customer_domain>)
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: jojo
    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

2.3. Modification de la configuration liée au RGPD

Pour autoriser les utilisateurs à pouvoir changer les alertes et la durée RGPD, une configuration spécifique est possible au niveau du composant IAM_Internal (notamment via le paramètre gdpr_alert_readonly (par défaut à true)).

Veuillez consulter la page dédiée à RGPD pour plus d’informations sur les configurations associées.

2.4. Suppression d’applications:

Veuillez consulter la page dédiée à la suppression des applications pour plus d’informations sur la procédure associée.