Encadrer les changements de statut avec les règles de transition
Réserver un passage de statut à certains rôles, l'interdire, ou exiger des sous-tâches terminées, des champs remplis ou une recette acceptée.
- Palier
- À partir de Team
- Droit requis
- Workflows › Gérer les règles de transitionPar défaut : Product Owner, Scrum Master, ainsi que le propriétaire et les admins du projet.
Sans règle, tout est libre
Par défaut, n'importe quel membre qui peut modifier un ticket peut le passer de n'importe quel statut à n'importe quel autre. Les règles de transition ajoutent des garde-fous. Elles se gèrent dans Paramètres › Projet, carte Workflow.
Les types de règles
Ajouter une règle, puis choisissez l'élément concerné (tickets, epics ou Super Epics), le statut de départ (ou « n'importe quel statut »), le statut d'arrivée, et le type de règle :
| Type | Effet | S'applique à |
|---|---|---|
| Réservé à certains rôles | seuls les rôles cochés font le passage | tous, sauf propriétaire et admins |
| Droit requis | il faut détenir un droit précis | tous, sauf propriétaire et admins |
| Interdire le passage | personne ne fait ce passage | tous, sauf propriétaire et admins |
| Sous-tâches terminées | toutes les sous-tâches du ticket doivent être cochées | tout le monde |
| Champs obligatoires | les champs choisis doivent être remplis | tout le monde |
| Recette acceptée | la dernière recette du ticket doit être acceptée | tout le monde |
Les règles qui portent sur qui déplace ne bloquent jamais le propriétaire ni les admins du projet : c'est le garde-fou qui évite de verrouiller un projet. Celles qui portent sur l'état du ticket s'appliquent à tous.
Plusieurs rôles autorisés : une seule règle
Des règles sur le même passage s'additionnent : toutes doivent être respectées. Pour autoriser le Product Owner ou le QA, faites une seule règle et cochez les deux rôles ; deux règles séparées n'autoriseraient plus personne. Manifst signale ce genre d'anomalie dans la carte Workflow.
Trois façons de voir les règles
- Liste : toutes les règles, une par ligne.
- Matrice : chaque case croise un statut de départ et un statut d'arrivée, et indique si le passage est libre, réservé, conditionné ou interdit.
- Parcours : le flux du projet dessiné, avec les passages sous règle.
Ce que voit l'équipe
Un passage refusé affiche la raison : « Ce projet interdit le passage de… à… », « réservé à… », « demande le droit… ». Voir Une action est refusée.
Les changements de statut venus d'un connecteur (synchronisation avec Jira, Azure Boards ou Linear, fermeture par une pull request) ne sont pas soumis aux règles.
Palier
Créer et modifier des règles demande un palier qui inclut la gouvernance. Sur le palier gratuit, les règles déjà en place restent visibles et continuent de s'appliquer.