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:
```yaml
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:
```yaml
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 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 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:
```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.