History

Imugiii b85563b1b8 All checks were successful CI / secret-scan (pull_request) Successful in 8s Details CI / static-tests (pull_request) Successful in 34s Details CI / auto-merge (pull_request) Successful in 5s Details CI / php-lint (pull_request) Successful in 22s Details CI / secret-scan (push) Successful in 9s Details CI / php-lint (push) Successful in 24s Details CI / static-tests (push) Successful in 37s Details CI / auto-merge (push) Has been skipped Details fix(db): moindre privilege pour le user applicatif (drop GRANT ALL) L'image mariadb cree MARIADB_USER avec GRANT ALL PRIVILEGES sur la base, ce qui donnait au code back-office expose un acces DDL/DROP/GRANT dont il n'a aucun usage (les migrations tournent en root). La doc (compose, backup-db.sh) decrivait pourtant un moindre privilege jamais applique. - db/init/10-scope-app-user.sh : script d'init MariaDB (volume vierge) qui REVOKE ALL puis GRANT le set restreint SELECT/INSERT/UPDATE/DELETE + SHOW VIEW/TRIGGER/ LOCK TABLES (DML + besoins mysqldump), parametre sur MARIADB_USER/DATABASE. - docker-compose.yml : montage de db/init en /docker-entrypoint-initdb.d (ro). - backup-db.sh : commentaire aligne sur le set reel (mysqldump --single-transaction n'exige que SELECT + SHOW VIEW/TRIGGER). Verifie : sur volume vierge le user ressort scope (plus de ALL PRIVILEGES) ; sur la base dev (scopee manuellement, hors volume vierge) /api/health=200 (SELECT) et les 13 tests d'integration passent (DML create/update/delete en tant que wakdo).		2026-06-16 11:53:38 +00:00
..
init	fix(db): moindre privilege pour le user applicatif (drop GRANT ALL)	2026-06-16 11:53:38 +00:00
migrations	feat(admin): throttle du PIN d action sensible par acteur (RG-T22) (#18 )	2026-06-16 00:06:33 +02:00
seeds	feat(db): seed data - RBAC matrix + INCO allergens + admin user + catalogue (9 cat / 53 products / 13 menus + composition)	2026-06-15 13:45:14 +00:00
migrate.sh	feat(db): initial schema DDL (21 tables) + migration runner (#6 )	2026-06-15 15:36:05 +02:00
README.md	feat(db): initial schema DDL (21 tables) + migration runner (#6 )	2026-06-15 15:36:05 +02:00
seed.sh	feat(db): initial schema DDL (21 tables) + migration runner (#6 )	2026-06-15 15:36:05 +02:00

README.md

Base de donnees - migrations & seeds

Transcription executable du MLD (docs/merise/mld.md, 21 tables) vers MariaDB 11.4.

Arborescence

db/
  migrations/   migrations SQL versionnees, appliquees dans l'ordre lexicographique
    0001_init_schema.sql   schema initial : 21 tables, FK, CHECK, index (InnoDB, utf8mb4)
  seeds/        donnees de demonstration (a venir : roles/permissions, allergenes, catalogue)
  migrate.sh    runner de migrations (idempotent)

Appliquer les migrations

bash db/migrate.sh            # applique les migrations en attente
bash db/migrate.sh --status   # liste l'etat sans rien appliquer

Le runner cible le conteneur wakdo-db et lit les identifiants dans .env (DB_NAME, DB_ROOT_PASSWORD). Il maintient une table schema_migrations (une ligne par fichier applique) : relancer ne rejoue que les nouvelles migrations. La cible make migrate est destinee a appeler ce script.

Conventions

Une migration = un fichier NNNN_description.sql. Un fichier deja applique en commun n'est plus edite : on ajoute une nouvelle migration pour corriger.
Pas de CREATE DATABASE / USE dans les fichiers : la base cible est choisie par le runner.
Le schema suit le MLD v0.2 a la lettre : montants en centimes (INT UNSIGNED), vat_rate en pour-mille, service_day NON materialise (calcule applicatif, decision D6), stock signe (survente), journaux append-only (stock_movement, audit_log).
Verification : le DDL a ete applique sur une instance MariaDB 11.4 reelle (21 tables, 28 FK, 22 CHECK) sans erreur avant integration.