tristan
d66288d061
Auto Tag Develop / tag (push) Successful in 13s
## Contexte (incident prod) Le correctif #31 (dirty-tracking front) ne protège que les sessions chargeant le nouveau bundle. Un **vieil onglet** ouvert avant déploiement tourne encore sur l'ancien JS et envoie toute la grille périmée. Hier soir, un onglet ouvert le matin a **supprimé ~10 lignes d'heures** saisies dans la journée par d'autres utilisateurs (journal BDD à l'appui : 1 save = 2 updates + 8 deletes de lignes intactes). Cause : le backend traitait toute **entrée vide comme une suppression**, sans aucune garde indépendante du client. ## Correctif — suppression sur intention explicite (`delete: true`) `WorkHourBulkUpsertProcessor` ne supprime une ligne existante sur entrée vide **que si l'entrée porte `delete: true`**. Sinon → **no-op** (ligne préservée). Aucune grille périmée, quel que soit le client (vieil onglet inclus), ne peut plus détruire une saisie concurrente. La création de ligne technique de validation reste limitée à `null === $existing`. Le front (à jour) pose `delete: true` sur une ligne **vidée volontairement** (helper `isEntryEmpty`, appliqué après le filtre dirty-tracking) → suppression métier conservée. Flag optionnel ajouté au DTO front (`WorkHourEntryPayload`) et back (`WorkHourBulkUpsert`), défaut `false`. ## Testabilité Le processor dépend désormais des interfaces repo (`EmployeeScopedRepositoryInterface` / `WorkHourReadRepositoryInterface`, repos concrets `final` non mockables) → nouveau test unitaire `WorkHourBulkUpsertProcessorTest` (no-op sans flag / suppression avec flag / update normal). ## Limite résiduelle (choix : suppression explicite, pas verrou optimiste) L'**édition explicite** d'une ligne sur données périmées peut encore écraser une saisie concurrente sur cette même ligne. Seule la **suppression** est blindée. ## Vérification - **267 tests PHPUnit OK** (dont 3 nouveaux), via le pre-commit hook. - Front : revue de code (pas de harnais de tests front). ## Doc - `doc/hours-save-dirty-tracking.md`, `CLAUDE.md`, doc in-app (`documentation-content.ts`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Reviewed-on: #36 Co-authored-by: tristan <tristan@yuno.malio.fr> Co-committed-by: tristan <tristan@yuno.malio.fr>
SIRH
Application de gestion des absences employée
Importer un dump de prod en dev
Sur adminer fait un export bdd :
- Sortie : enregistrer
- Format : SQL
- Tables : DROP+CREATE, Incrément automatique, Déclencheurs
- Données : INSERT
Supprime la bdd et créer la bdd :
docker compose exec -T db psql -U root -d sirh -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
Remplie la base avec le dump :
docker compose exec -T db psql -U root -d sirh < sirh.sql
Mettre SUPER_ADMIN sur un user
UPDATE users SET roles = '["ROLE_ADMIN","ROLE_SUPER_ADMIN"]' WHERE username = 'emilie';
Récupérer la bdd de prod en local
Sur le serveur de prod, créer le dump :
sudo -u postgres pg_dump --no-owner --no-privileges --clean --if-exists sirh_prod > /tmp/sirh_prod_$(date +%F).sql
En local, récupérer le fichier et l'importer (remplace YYYY-MM-DD par la date du dump) :
scp user@<serveur>:/tmp/sirh_prod_YYYY-MM-DD.sql ~/workspace/SIRH/sirh.sql
docker compose exec -T db psql -U root -d sirh -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
docker compose exec -T db psql -U root -d sirh < ~/workspace/SIRH/sirh.sql