# Variabilisation et modifications possibles pré-installation ## 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: ```yaml portal_categories: : title: " order: : title: "" displayTitle: order: ``` 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: ```yaml customer-init: profiles: - name: description: level: app-name: roles: - - - ... profiles-groups: - name: description: level: profiles: - - - ... users: - last-name: first-name: profiles-group-name: level: email-prefix: tenant-profiles: - name: description: level: app-name: roles: - - - ... admin-profiles: - name: description: app-name: level: roles: - - - ... ``` 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` ### 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@) * 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: ```yaml 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 ``` ## 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](RGPD.md) pour plus d'informations sur les configurations associées. ## Suppression d'applications: Veuillez consulter la [page dédiée à la suppression des applications](Personnalisation_applications.md) pour plus d'informations sur la procédure associée.