59 lines
2.7 KiB
Markdown
59 lines
2.7 KiB
Markdown
# Projets & Workflows
|
|
|
|
## Qu'est-ce qu'un projet ?
|
|
|
|
Un projet regroupe un ensemble de **tâches**, **time entries** et éventuellement **tickets client**. Il est défini par :
|
|
|
|
- Un **code court** (2-10 lettres majuscules, ex: `SIRH`, `CRM`) qui préfixe les numéros de tâches
|
|
- Un **client** optionnel (ou interne si null)
|
|
- Une **couleur** d'identification
|
|
- Un **workflow** (obligatoire) qui définit ses colonnes kanban
|
|
|
|
## Qu'est-ce qu'un workflow ?
|
|
|
|
Un **workflow** est un *jeu de statuts kanban* réutilisable. Au lieu d'avoir une liste globale de statuts comme dans la plupart des outils, chaque projet a son propre kanban adapté à sa façon de travailler.
|
|
|
|
### Exemple
|
|
|
|
| Workflow | Statuts |
|
|
|---|---|
|
|
| **Standard** (par défaut) | À faire → En cours → Bloqué → En attente de validation → Terminé |
|
|
| **DevKanban** | Backlog → Spec → In Dev → Review PR → QA → Done |
|
|
| **Support** | Nouveau → Diagnostic → Résolu |
|
|
|
|
Tu peux créer autant de workflows que tu veux depuis **Admin → Workflows**.
|
|
|
|
## Les 5 catégories canoniques
|
|
|
|
Chaque statut, peu importe son workflow, appartient à **une catégorie canonique** parmi :
|
|
|
|
| Catégorie | Description |
|
|
|---|---|
|
|
| `todo` | À faire — pas encore commencé |
|
|
| `in_progress` | En cours — quelqu'un bosse dessus |
|
|
| `blocked` | Bloqué — attente d'une dépendance |
|
|
| `review` | En validation — relecture, PR, QA |
|
|
| `done` | Terminé — close |
|
|
|
|
> 🎯 **Pourquoi des catégories ?** Pour que la vue *Mes tâches* puisse regrouper des tâches venant de projets avec des workflows différents (ex: une tâche "In Dev" de DevKanban et "En cours" de Standard apparaissent dans la même colonne `in_progress`).
|
|
|
|
## Changer le workflow d'un projet
|
|
|
|
1. Ouvrir le projet → **Modifier le projet** (drawer)
|
|
2. Section **Workflow** → cliquer sur **Changer de workflow**
|
|
3. Sélectionner le workflow cible
|
|
4. **Mapper chaque statut source vers un statut cible** (le mapping est pré-rempli automatiquement par catégorie)
|
|
5. **Confirmer** — toutes les tâches migrent dans une seule transaction
|
|
|
|
### Règles du mapping
|
|
|
|
- ✅ Chaque statut actuellement utilisé par une tâche **doit** être mappé (sinon erreur 422)
|
|
- ✅ Un statut peut être mappé vers `null` → la tâche passe en backlog (sans statut)
|
|
- ❌ Tu ne peux pas mapper vers un statut qui n'appartient pas au workflow cible
|
|
|
|
## Supprimer un workflow
|
|
|
|
Tu peux supprimer un workflow uniquement s'il n'est **lié à aucun projet** (HTTP 409 sinon). Réassigne d'abord les projets vers un autre workflow.
|
|
|
|
> ⚠️ Le workflow **Standard** ne peut pas être supprimé tant qu'il reste le défaut (un seul workflow peut avoir `isDefault=true` à la fois, garanti par un listener Doctrine).
|