# Example — Roles custom Acadenice

Roles RBAC custom declares **cote DocAdenice (R2)**, projetes vers le
bridge via le claim JWT `acadenice_permissions[]`.

> Le bridge n'a pas de role hardcode. Il accepte les permissions presentes
> dans le claim et les mappe directement vers les scopes generiques
> `read:tables` / `write:tables` (ou plus fin si DocAdenice le decide).

## Roles fonctionnels

### Formateur

Forme les apprentis sur des modules CFA. Peut saisir ses heures realisees.

| Permission   | Justification                                     |
|--------------|---------------------------------------------------|
| `read:tables`| Voir personnes, formations, blocs, modules, ses attributions |
| `write:tables`| Saisir attribution.heures_realisees              |

Filtrage cote frontend : ne voit que les attributions ou
`attribution_personne` matche son `personne_id`.

### Developpeur

Travaille sur des projets agence. Saisit ses interventions.

| Permission   | Justification                                     |
|--------------|---------------------------------------------------|
| `read:tables`| Voir clients, projets, taches, ses interventions  |
| `write:tables`| Creer interventions sur ses taches               |

Filtrage cote frontend : ne voit que ses interventions et les taches
auxquelles il est assigne.

### Direction

Vue 360 lecture seule.

| Permission   | Justification                                     |
|--------------|---------------------------------------------------|
| `read:tables`| Toutes les tables, vue dashboard agregee          |

### Support

Operations administratives, pas de saisie metier.

| Permission   | Justification                                     |
|--------------|---------------------------------------------------|
| `read:tables`| Toutes les tables                                 |
| `write:tables`| Mises a jour ponctuelles (statut, notes)         |

### Admin

Toutes operations sans restriction.

| Permission   | Justification                                     |
|--------------|---------------------------------------------------|
| `admin:*`    | Wildcard couvre tout                              |

## Mapping JWT claim -> scopes bridge

DocAdenice (R2) projettera dans le JWT :

```json
{
  "sub": "authentik-uuid-1234",
  "email": "pierre@acadenice.fr",
  "groups": ["acadenice-formateurs"],
  "acadenice_permissions": ["read:tables", "write:tables"]
}
```

Le bridge :
- ignore `groups` sauf si un mapping `AUTH_GROUPS_SCOPES_MAP` est configure
- lit `acadenice_permissions[]` directement et l'union avec les groupes mappes

Resultat dans `c.var.user.scopes` du bridge :
`['read:tables', 'write:tables']` -> autorise GET / POST / PATCH / DELETE
sur `/api/v1/tables/*`.

## Notes de design

- Le bridge ne fait **aucun filtrage par tableId** : si l'utilisateur a
  `read:tables`, il peut lire n'importe quelle table. Le filtrage fin
  (« ce formateur ne voit que ses attributions ») est applique cote
  frontend / DocAdenice via les filtres Baserow ou des middlewares
  applicatifs sur le frontend.
- Pour une protection plus stricte, DocAdenice peut emettre des permissions
  scope-table comme `read:tables:609` (table Personne) — le bridge
  acceptera, mais il faut alors etendre `requireScope` cote routes (R3).
- Les permissions explicites declarees dans le JWT priment sur les groups :
  c'est volontaire pour permettre les overrides individuels (`personne X
  est formateur sauf qu'on lui retire write:tables temporairement`).