# Permissions des tables

Sovrium contrôle l'accès aux enregistrements avec un **contrôle d'accès basé sur les rôles (RBAC)** au niveau de la table, des **permissions par champ** pour un contrôle granulaire des colonnes, et des **prédicats au niveau ligne** optionnels pour un cloisonnement par ligne. Un accès non autorisé renvoie **404** (jamais 403) afin d'empêcher l'énumération des enregistrements.

## Valeurs de permission

Chaque opération accepte l'un de trois formats :

| Valeur                | Signification                                            |
| --------------------- | -------------------------------------------------------- |
| `all`                 | Tout le monde, y compris les visiteurs non authentifiés. |
| `authenticated`       | Tout utilisateur connecté.                               |
| `['admin', 'editor']` | Uniquement les noms de rôles listés (un tableau).        |

Les trois rôles intégrés sont `admin`, `member` et `viewer` (du plus élevé au plus bas). Des noms de rôles personnalisés sont également acceptés dans la forme tableau.

## Permissions au niveau de la table

Définissez `permissions` sur une table pour conditionner chaque opération.

| Opération         | Contrôle qui peut…                                               |
| ----------------- | ---------------------------------------------------------------- |
| `read`            | Consulter les enregistrements.                                   |
| `comment`         | Ajouter des commentaires aux enregistrements.                    |
| `create`          | Créer de nouveaux enregistrements.                               |
| `update`          | Modifier les enregistrements existants.                          |
| `delete`          | Effectuer la suppression douce d'enregistrements.                |
| `restore`         | Restaurer les enregistrements supprimés en douceur.              |
| `permanentDelete` | Retirer définitivement les enregistrements supprimés en douceur. |
| `fields`          | Permissions de lecture/écriture par champ (voir ci-dessous).     |
| `inherit`         | Hériter de toutes les permissions d'une table parente nommée.    |

```yaml
permissions:
  read: all
  comment: authenticated
  create: [admin, editor]
  update: [admin, editor]
  delete: [admin]
  restore: [admin]
  permanentDelete: [admin]
```

## Permissions par champ

Restreignez l'accès en lecture/écriture à des colonnes spécifiques sous `permissions.fields`. Chaque entrée nomme un `field` et, optionnellement, ses audiences `read` et `write` (mêmes trois formats). Lorsqu'une permission de champ est omise, elle hérite du `read` au niveau de la table (pour la lecture) ou de `create`/`update` (pour l'écriture).

| Propriété | Description                                                                  |
| --------- | ---------------------------------------------------------------------------- |
| `field`   | Nom du champ auquel cette permission s'applique.                             |
| `read`    | Qui peut lire (SELECT) ce champ. Hérite du `read` de la table si non défini. |
| `write`   | Qui peut écrire (INSERT/UPDATE) ce champ. Hérite si non défini.              |

```yaml
permissions:
  read: authenticated
  fields:
    - { field: salary, read: [admin, hr], write: [admin] }
    - { field: department, read: all, write: [admin] }
```

## Permissions au niveau ligne

Définissez `rowLevelPermissions` pour un cloisonnement en défense en profondeur. Chaque opération CRUD peut porter un prédicat `when` côté serveur qui est ajouté comme filtre à chaque requête retournant des enregistrements. La barrière de rôle s'exécute en premier ; le prédicat au niveau ligne filtre ensuite dans la portée du rôle autorisé.

Un prédicat est `{ field, operator, value }` :

| Champ      | Description                                                                                                            |
| ---------- | ---------------------------------------------------------------------------------------------------------------------- |
| `field`    | Le champ de la table, ou une chaîne de relation comme `project.client_id`, sur lequel filtrer.                         |
| `operator` | `eq`, `neq` ou `in` (appartenance à un tableau).                                                                       |
| `value`    | Un littéral (chaîne/nombre/booléen/tableau) **ou** une référence `$currentUser` résolue par requête depuis la session. |

```yaml
rowLevelPermissions:
  read:
    when:
      field: client_id
      operator: in
      value: { kind: currentUser, path: { kind: assignment, tableSlug: clients } }
  write:
    when:
      field: client_id
      operator: in
      value: { kind: currentUser, path: { kind: assignment, tableSlug: clients } }
```

:::callout
**404, pas 403 — anti-énumération.** Lorsqu'une requête échoue à l'autorisation (au niveau de la table, du champ ou de la ligne), Sovrium renvoie **404 Not Found** plutôt que 403 Forbidden. Cela empêche les attaquants de découvrir quels enregistrements ou tables existent en sondant les codes de statut.
:::

## Permissions Ressource:Action

Pour des contextes de permission plus larges (plugin admin, clés API), Sovrium prend également en charge une carte `resource: [actions]` où chaque ressource liste les actions autorisées et `*` signifie toutes les actions :

```yaml
users: [read, list]
posts: [create, read, update, delete]
analytics: ['*']
```