feat(workflow) : workflows de statuts par projet (kanban custom) #3

Merged
matthieu merged 26 commits from feat/project-workflows into develop 2026-05-20 07:44:10 +00:00
Owner

Résumé

Chaque projet a désormais son propre workflow (jeu de statuts kanban réutilisable défini en admin).

  • Backend : entité Workflow, TaskStatus.workflow + TaskStatus.category (5 catégories canoniques), Project.workflow requis (RESTRICT). Validation cross-entity : un statut doit appartenir au workflow du projet de la tâche.
  • Endpoint : POST /api/projects/{id}/switch-workflow (transaction unique, mapping source→cible obligatoire pour chaque statut référencé)
  • UI admin : onglet Workflows (remplace Statuts) avec drawer pour créer/éditer un workflow et ses statuts inline
  • Kanban projet : utilise project.workflow.statuses au lieu de la collection globale
  • my-tasks : kanban groupé par les 5 catégories canoniques (todo / in_progress / blocked / review / done) avec badge statut sur chaque card
  • Switch projet : modal ProjectWorkflowSwitchModal avec pré-remplissage par catégorie
  • TaskBulkActions : désactive le bulk-status sur sélection multi-projets
  • MCP : list-statuses?projectId=..., nouveaux list-workflows et switch-project-workflow (ROLE_ADMIN)

Spec : docs/superpowers/specs/2026-05-19-project-workflows-design.md
Plan : docs/superpowers/plans/2026-05-19-project-workflows.md

Migrations

4 migrations successives :

  • M1 crée la table workflow + seed Standard (isDefault=true)
  • M2 ajoute workflow_id + category sur task_status avec backfill strict (mapping des 5 labels standards → catégories ; échec explicite si label hors mapping)
  • M3 ajoute workflow_id requis sur project (RESTRICT) avec backfill vers Standard
  • M4 aligne le schéma avec les conventions Doctrine (indexes + IDENTITY) et réaligne la séquence workflow.id (évite conflit avec le row Standard de M1)

Test plan

  • Migrations passent sur la prod (les 5 labels standards de prod sont mappés ; M2 échoue avec message explicite si dérive)
  • Création workflow custom + statuts catégorisés via l'admin
  • Switch d'un projet vers un autre workflow → mapping pré-rempli par catégorie, transaction OK, kanban projet utilise les nouvelles colonnes
  • my-tasks affiche 5 colonnes par catégorie + badge statut sur chaque card
  • Suppression workflow lié → 409 avec message clair
  • MCP : list-workflows, list-statuses?projectId, switch-project-workflow, create-task rejet inter-workflow
  • Bulk-status désactivé sur sélection multi-projets dans my-tasks

Validation

Migrations testées sur un dump prod restauré localement (lesstime_prod_test) : 13 projets, 379 tâches, 5 statuts catégorisés sans erreur. Endpoint switch-workflow validé via curl. UI testée en local.

🤖 Generated with Claude Code

## Résumé Chaque projet a désormais son propre workflow (jeu de statuts kanban réutilisable défini en admin). - **Backend** : entité `Workflow`, `TaskStatus.workflow` + `TaskStatus.category` (5 catégories canoniques), `Project.workflow` requis (RESTRICT). Validation cross-entity : un statut doit appartenir au workflow du projet de la tâche. - **Endpoint** : `POST /api/projects/{id}/switch-workflow` (transaction unique, mapping source→cible obligatoire pour chaque statut référencé) - **UI admin** : onglet `Workflows` (remplace `Statuts`) avec drawer pour créer/éditer un workflow et ses statuts inline - **Kanban projet** : utilise `project.workflow.statuses` au lieu de la collection globale - **my-tasks** : kanban groupé par les 5 catégories canoniques (todo / in_progress / blocked / review / done) avec badge statut sur chaque card - **Switch projet** : modal `ProjectWorkflowSwitchModal` avec pré-remplissage par catégorie - **TaskBulkActions** : désactive le bulk-status sur sélection multi-projets - **MCP** : `list-statuses?projectId=...`, nouveaux `list-workflows` et `switch-project-workflow` (ROLE_ADMIN) Spec : `docs/superpowers/specs/2026-05-19-project-workflows-design.md` Plan : `docs/superpowers/plans/2026-05-19-project-workflows.md` ## Migrations 4 migrations successives : - **M1** crée la table `workflow` + seed `Standard` (isDefault=true) - **M2** ajoute `workflow_id` + `category` sur `task_status` avec backfill strict (mapping des 5 labels standards → catégories ; échec explicite si label hors mapping) - **M3** ajoute `workflow_id` requis sur `project` (RESTRICT) avec backfill vers Standard - **M4** aligne le schéma avec les conventions Doctrine (indexes + IDENTITY) et réaligne la séquence workflow.id (évite conflit avec le row Standard de M1) ## Test plan - [ ] Migrations passent sur la prod (les 5 labels standards de prod sont mappés ; M2 échoue avec message explicite si dérive) - [ ] Création workflow custom + statuts catégorisés via l'admin - [ ] Switch d'un projet vers un autre workflow → mapping pré-rempli par catégorie, transaction OK, kanban projet utilise les nouvelles colonnes - [ ] my-tasks affiche 5 colonnes par catégorie + badge statut sur chaque card - [ ] Suppression workflow lié → 409 avec message clair - [ ] MCP : list-workflows, list-statuses?projectId, switch-project-workflow, create-task rejet inter-workflow - [ ] Bulk-status désactivé sur sélection multi-projets dans my-tasks ## Validation Migrations testées sur un dump prod restauré localement (`lesstime_prod_test`) : 13 projets, 379 tâches, 5 statuts catégorisés sans erreur. Endpoint switch-workflow validé via curl. UI testée en local. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
matthieu added 26 commits 2026-05-19 18:57:49 +00:00
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
matthieu force-pushed feat/project-workflows from b3f32e4c6c to 5fb7fbe66c 2026-05-19 18:59:53 +00:00 Compare
matthieu merged commit 595b8f5be3 into develop 2026-05-20 07:44:10 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MALIO-DEV/Lesstime#3