> ## Documentation Index
> Fetch the complete documentation index at: https://api-documentation.kare-app.fr/llms.txt
> Use this file to discover all available pages before exploring further.
# Rôles et permissions
### Organisations
* Une organisation est créée **inactive** et peut être activée à tout moment, souvent une fois entièrement configurée.
* Tant qu'elle est inactive, ses utilisateurs ne peuvent pas accéder à l'app (les invitations peuvent quand même partir).
* Chaque organisation a **un owner**, désigné par l'équipe Akord : le niveau le plus haut, au-dessus des admins — accès total implicite. Il ne peut être ni rétrogradé ni supprimé (seul un changement d'owner le remplace).
### Rôles par défaut
Trois rôles fournis dans chaque organisation, qui évoluent automatiquement avec les nouvelles fonctionnalités :
* **admin** : tout
* **operator** : tout sauf l'administration de l'organisation
* **read-only** : lecture seule
### Rôles de librairie
Modèles de rôles proposés par Akord, gérés dans le back-office comme les autres librairies. En utiliser un crée un rôle **custom** dans l'organisation, modifiable ensuite librement — il garde un lien avec son modèle d'origine.
### Rôles custom
Créés par les admins de l'organisation en choisissant les droits dans un catalogue. On ne peut pas accorder un droit qu'on n'a pas soi-même.
Un rôle encore attribué à des utilisateurs ne peut pas être supprimé : il faut d'abord le retirer.
### Cumul et périmètre (units)
* Un utilisateur peut cumuler plusieurs rôles.
* À chaque rôle attribué, on sélectionne explicitement les **units** (établissements) concernées — par exemple : operator sur le siège, read-only sur une agence.
* Aucun unit sélectionné = uniquement les droits d'organisation du rôle, aucune donnée terrain.
* Les admins et l'owner couvrent toujours toute l'organisation.
Les organisations audit n'ont pas d'units : les rôles s'y attribuent sans cette dimension.
### Hiérarchie
Hiérarchie simple : **owner > admin > tous les autres rôles** (égaux entre eux). On n'agit que vers le bas :
* Seul un admin, ou l'owner, peut nommer ou rétrograder un admin.
* Un utilisateur qui gère les membres sans être admin ne peut jamais toucher à un admin, ni s'élever lui-même.
***
les tables: roles, libraryRoles
Il y a 3 types de droits:
* les droits que nous faisons évoluer : "admin", "operator", "readonly".
* les droits template (doivent être copier, instant T)
* les droits custom
* Il faudra définir 1 owner par organisation depuis le back office
### Role
* **Capabilities**: string\[]
* '**access**:site:\': filtre (backend & front)
* '**action**:document:send': action (backend & front)
* '**view**:commission': capabilities utilisé seulement dans le front
* ~~defaultSettings: arborescence de settings~~
Les capabilities & settings dans les rôles sont cumulables.
Tous les roles sont visibles et associables pour les autres utilisateurs.
