Wiki/examples/acadenice-formation-hub/example-roles.md
Corentin JOGUET 2ed73fa948
Some checks are pending
CI / Lint bridge (Biome) (push) Waiting to run
CI / Type-check bridge (push) Blocked by required conditions
CI / Tests unit bridge (push) Blocked by required conditions
CI / Tests integration bridge (push) Blocked by required conditions
CI / Security scan (push) Waiting to run
CI / Docker build + healthcheck (push) Blocked by required conditions
feat(bridge): R1 refactor proxy generique style Notion
Pivot strategique : DocAdenice = produit Notion-like generique. Le bridge
est livre vide a un user qui cree ses tables Baserow comme il veut. Code
sans aucune ontologie metier.

Suppressions :
- 9 entites domain metier (Personne, Formation, Bloc, Module, Attribution,
  Client, Projet, Tache, Intervention) + types.ts (Role, statuts)
- baserow-repo.ts (mega-fichier 554 LOC avec 9 repos heritant BaseRepo)
- 6 routes metier (personnes, formations, projets, modules, interventions,
  attributions) + tests associes
- Lookup PersonneRepo.findByEmail dans middleware auth
- Mapping DEFAULT_ROLE_SCOPES dans middleware/scopes.ts
- Cascade rollup metier dans webhooks/baserow-handler.ts

Ajouts :
- Domain generique : Table, Row, Field, View + schemas zod refondus
- 4 repos generiques : tables / rows / fields / views
- Route unique routes/tables.ts avec 9 endpoints REST CRUD generiques
- Claim JWT acadenice_permissions[] lu directement dans le middleware auth
  (alimente par RBAC dynamique cote DocAdenice en R2)
- examples/acadenice-formation-hub/ : README + seed-baserow.md schema
  9 tables + example-roles.md (Formateur, Developpeur, Direction, Support,
  Admin avec permissions generiques)

Refactors :
- BaserowClient etendu : listTables, getTable, listFields, listViews,
  getGridViewRows
- middleware/auth.ts : extractPermissions(payload), AuthenticatedUser
  remplace roles[] par permissions[]
- middleware/scopes.ts : computeOidcScopes(groups, permissions, map)
- webhooks/baserow-handler.ts : invalidation generique
  bridge:tables:<tableId>:* sans cascade cross-table
- lib/cache.ts : invalidateEntity -> invalidateTable(redis, tableId, rowId?)
- container.ts : drop tableIds, RepoSet={tables, rows, fields, views}
- 501 NOT_IMPLEMENTED si DB token sur endpoints /tables qui exigent JWT

Tests : 250/250 verts (depuis 319). Coverage : domain 98.9%, adapters 89%,
auth 97.08%, rate-limit 100%, cache 100%, webhooks 100%.

Quality gates verts : typecheck, lint biome, vitest, coverage thresholds.

Refs: R1 dans le pivot strategique DocAdenice Notion-like generique.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 22:12:32 +02:00

3.4 KiB

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 :

{
  "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).