docs: add review.md decision log
This commit is contained in:
SaidSoighiri94
@@ -0,0 +1,95 @@
|
||||
# review.md — Journal des décisions EME
|
||||
|
||||
> Ce fichier trace chaque étape réalisée et chaque choix technique, avec sa justification.
|
||||
> Il est mis à jour au fil de l'avancement. Lecture du plus ancien (haut) au plus récent (bas).
|
||||
>
|
||||
> Règles métier -> `docs/regles-metier/regles-gestion.md` · Contexte -> `CONTEXT.md` · Plan -> `TODO.md`
|
||||
|
||||
---
|
||||
|
||||
## Conventions et choix transverses
|
||||
|
||||
Ces décisions s'appliquent à tout le projet, sauf mention contraire.
|
||||
|
||||
| Décision | Pourquoi |
|
||||
|---|---|
|
||||
| Statuts métier en `String` côté Prisma (pas d'enum natif) | SQL Server ne supporte pas les enums Prisma. Les valeurs sont validées côté TypeScript via `src/models/enums.ts`. |
|
||||
| Timestamps automatiques : `createdAt @default(now())`, `updatedAt @updatedAt` | Évite d'avoir à fournir ces valeurs manuellement ; `updatedAt` est géré par Prisma au runtime. |
|
||||
| `actif Boolean @default(true)` | Une entité créée est active par défaut. |
|
||||
| `@unique` sur les identifiants fonctionnels | Intégrité : un identifiant en double casse l'authentification / l'unicité métier. |
|
||||
| Champs nullable selon les cardinalités `0..1` du diagramme de classes | Un champ non connu à la création (ex. date de retour) ou optionnel doit être `NULL`, sinon le workflow métier est bloqué. |
|
||||
| `onDelete: NoAction, onUpdate: NoAction` sur les données de traçabilité (Emprunt, Checklist, ChecklistElement, Anomalie, Historique) | Ces données ne doivent jamais être supprimées/altérées automatiquement en cascade. Toute suppression sera explicite côté service. Évite aussi l'erreur SQL Server "multiple cascade paths". |
|
||||
| ERD tenu à jour en miroir du schéma (`docs/conceptions/uml/ERD.md`) | La source de vérité doit refléter le code réel (nullable, `UK`, etc.). |
|
||||
| Workflow Git : commits sur `develop` uniquement | `master` est figé ; `develop` reste toujours à jour de `master` (aucune divergence puisque master ne bouge plus). |
|
||||
| Process avant chaque migration : `prisma format` -> `prisma validate` -> `npm run build` -> migration | Détecter toute erreur de schéma/typage avant de toucher la base. |
|
||||
|
||||
### Note outillage — migrations en environnement non-interactif
|
||||
|
||||
`prisma migrate dev` se bloque quand il doit demander une confirmation (ex. ajout de contrainte `@unique` sur table existante) car le terminal est non-interactif.
|
||||
Contournement utilisé : générer le SQL avec `prisma migrate diff --from-config-datasource --to-schema ... --script`, écrire le fichier de migration, puis appliquer avec `prisma migrate deploy`. Résultat strictement identique à `migrate dev`, sans perte de données.
|
||||
En terminal interactif (VS Code), `migrate dev` fonctionne normalement (taper `y`).
|
||||
|
||||
---
|
||||
|
||||
## Journal chronologique
|
||||
|
||||
### Étape 0 — Audit initial
|
||||
- Constat : Block 0 (bootstrap) terminé mais non coché ; schéma à 4/16 entités ; aucune migration ; aucun commit Git.
|
||||
- Décision : compléter le schéma par petits blocs (et non d'un coup) pour valider/committer au fur et à mesure.
|
||||
|
||||
### Étape 1 — Configuration des migrations Prisma
|
||||
- Correction `DATABASE_URL` (mot de passe désaligné avec `DB_PASSWORD`).
|
||||
- Découverte : Prisma 7 interdit `url` dans `schema.prisma` -> la connexion vit dans `prisma.config.ts`. Ligne `url` retirée du datasource.
|
||||
|
||||
### Étape 2 — Modèles de référence (Campus, Role, Utilisateur, CategorieMateriel)
|
||||
- Defaults + timestamps auto ajoutés sur Campus, Utilisateur, CategorieMateriel (Role n'a pas de timestamps -> non modifié).
|
||||
- `@unique` sur `Role.code`, `Utilisateur.microsoftId`, `Utilisateur.email`.
|
||||
- `Utilisateur.classe` -> nullable : un `RESPONSABLE` n'a pas de classe (seuls les étudiants en ont).
|
||||
- ERD mis à jour en miroir (`UK`, `nullable`).
|
||||
- Choix laissé de côté : tailles `@db.NVarChar(n)` (colonnes restées en `NVARCHAR(1000)` par défaut). À reconsidérer plus tard.
|
||||
|
||||
### Étape 3 — Bloc A : Infrastructure (SallePret, PosteEmprunt) — commit `d026b75`
|
||||
- `SallePret` rattachée à `Campus` ; `PosteEmprunt` rattaché à `SallePret`. Conforme à l'ERD.
|
||||
|
||||
### Étape 4 — Bloc B : CarteEtudiante — commit `dfa73cd`
|
||||
- Rattachée à `Utilisateur`.
|
||||
- Dette notée : `qr_code` devrait être `@unique` (sert à l'identification, RG02) — non posé pour rester fidèle à l'ERD.
|
||||
|
||||
### Étape 5 — Bloc C : Matériel (Materiel, Accessoire, MaterielAccessoire) — commit `0774ee3`
|
||||
- Table de liaison `MaterielAccessoire` (sans timestamps, conforme ERD).
|
||||
- Dette notée : `@@unique([materielId, accessoireId])` et `Materiel.statut @default("DISPONIBLE")`.
|
||||
|
||||
### Étape 6 — Bloc D : Transactions (Emprunt, Checklist, ChecklistElement) — commit `6908a2b`
|
||||
- Champs de retour/optionnels nullable : `dateRetourReelle`, `modeIdentificationRetour`, `commentaireDepart`, `commentaireRetour`, `Checklist.commentaire`, `ChecklistElement.commentaire`.
|
||||
- Pourquoi : RG12 crée l'emprunt au départ ; les infos de retour n'existent pas encore. En `NOT NULL`, la création serait impossible.
|
||||
- `ChecklistElement.accessoireId` nullable : conforme au diagramme de classes (`Accessoire "0..1"`), un élément peut être un libellé libre sans accessoire catalogué.
|
||||
- Les 9 FK en `NoAction` : traçabilité + évitement des cascade paths.
|
||||
- ERD mis à jour en miroir (champs annotés `nullable`).
|
||||
|
||||
### Étape 7 — Stratégie Git : branche `develop`
|
||||
- Création de `develop` depuis `master`. Désormais tous les commits vont sur `develop` ; `master` figé au Bloc C.
|
||||
|
||||
### Étape 8 — Bloc E : Suivi (Anomalie, Notification, Historique) — commit `0fc9f9e`
|
||||
- Schéma 16/16 complet.
|
||||
- Nullable selon `0..1` : `Anomalie.traiteeParId` (null tant que non pris en charge), `observation`, `dateResolution` ; `Notification.anomalieId` ; les 5 FK optionnelles d'`Historique` (un événement n'a pas toujours d'emprunt/matériel/etc.).
|
||||
- Double relation `Anomalie` vers `Utilisateur` nommée : `@relation("AnomalieEtudiant")` (étudiant concerné) et `@relation("AnomalieResponsable")` (responsable qui traite).
|
||||
- Defaults : `Anomalie.detecteeAutomatiquement @default(true)`, `Notification.lu @default(false)`, `Notification.dateCreation @default(now())`.
|
||||
- Les 12 FK en `NoAction` (traçabilité).
|
||||
- `Notification` et `Historique` sans `updatedAt` (conforme ERD).
|
||||
- ERD mis à jour en miroir.
|
||||
|
||||
---
|
||||
|
||||
## Dette technique en attente
|
||||
|
||||
À traiter ensemble plus tard (avec mise à jour ERD en miroir) :
|
||||
|
||||
1. `CarteEtudiante.qr_code` -> `@unique` (identification, RG02)
|
||||
2. `MaterielAccessoire` -> `@@unique([materielId, accessoireId])` (un accessoire une seule fois par matériel)
|
||||
3. `Materiel.statut` -> `@default("DISPONIBLE")` (un matériel neuf est disponible, RG07)
|
||||
4. Tailles de colonnes `@db.NVarChar(n)` (actuellement `NVARCHAR(1000)` partout)
|
||||
5. Block 1 : middleware d'erreurs global, logs, ESLint + Prettier, Swagger/OpenAPI
|
||||
|
||||
---
|
||||
|
||||
*Dernière mise à jour : 2026-06-15 — Schéma 16/16, fin du Bloc E.*
|
||||
Reference in New Issue
Block a user