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
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>
59 lines
2.5 KiB
Markdown
59 lines
2.5 KiB
Markdown
# Example — Acadenice formation-hub
|
|
|
|
Cet exemple montre **un cas d'usage parmi d'autres** du bridge generique
|
|
DocAdenice / Notion-like : le suivi d'heures formateurs et developpeurs pour
|
|
le **CFA + Agence Acadenice**.
|
|
|
|
## Contexte
|
|
|
|
Acadenice est :
|
|
- un CFA (Centre de Formation des Apprentis) — heures de formation a tracer
|
|
- une Agence dev — heures de prestations a tracer
|
|
|
|
Une meme personne peut porter plusieurs roles : formateur (CFA), developpeur
|
|
(Agence), admin/direction/support transverse. La capacite annuelle est
|
|
splittee entre les deux activites.
|
|
|
|
## Pourquoi un exemple et pas du code metier dans le bridge
|
|
|
|
Le bridge DocAdenice est un **proxy generique style Notion**. Il expose
|
|
n'importe quelle table Baserow via `/api/v1/tables/*` sans rien savoir du
|
|
metier. La modelisation Acadenice (9 tables, formules de rollup, regles de
|
|
gestion) vit :
|
|
|
|
- **cote Baserow** : schema des 9 tables + formules + vues (cf
|
|
`seed-baserow.md`)
|
|
- **cote DocAdenice** : RBAC dynamique avec roles custom (Formateur,
|
|
Developpeur, Direction, Support) qui produisent des claims OIDC
|
|
`acadenice_permissions[]` (cf `example-roles.md`)
|
|
- **cote frontend** : interface metier (dashboards capacite, attribution
|
|
modules, saisie heures) consomme l'API generique du bridge
|
|
|
|
## Comment rejouer cet exemple
|
|
|
|
1. Provisionner Baserow avec les 9 tables decrites dans `seed-baserow.md`
|
|
2. Creer les roles custom DocAdenice de `example-roles.md`
|
|
3. Configurer le bridge : il proxie tout, pas de config metier specifique
|
|
4. Construire le frontend (Tiptap node-views ou pages dediees Docmost)
|
|
|
|
## Mapping bridge generique <-> ce metier
|
|
|
|
| Generique bridge | Vu dans cet exemple |
|
|
|---------------------------|----------------------------------------------|
|
|
| `/tables` | 9 tables : Personne, Formation, Bloc, ... |
|
|
| `/tables/:id/rows` | CRUD sur une de ces tables |
|
|
| Webhooks invalidation | Cache Redis invalide par tableId touche |
|
|
| Cascades cross-table | Faites cote Baserow via formules + lookups |
|
|
| Permissions `read:tables` | Donnees globalement par DocAdenice via OIDC |
|
|
| Permissions specifiques | Filtrees cote frontend selon role custom |
|
|
|
|
## Autres exemples envisageables
|
|
|
|
Le meme bridge pourrait servir :
|
|
|
|
- un CRM custom (3 tables : Contacts, Opportunites, Notes)
|
|
- un tracker de bugs (2 tables : Issues, Comments)
|
|
- une base d'inventaire IT (5 tables : Asset, Owner, Site, Maintenance, Log)
|
|
|
|
Aucun de ces cas ne necessite de modification du bridge — juste une config
|
|
Baserow + DocAdenice.
|