Workflows de ticket

Construisez des flux : à partir de chaque statut, vers quels statuts le ticket peut aller. Le kanban et l'écran du ticket obéissent à ces transitions.

Définit les statuts et les transitions autorisées. Une transition qui n'existe pas est une transition impossible pour l'utilisateur — si quelqu'un se plaint de « ne pas pouvoir déplacer la demande », c'est ici qu'il faut regarder, pas du côté des permissions.

Ici, vous créez et gérez un workflow de demande : le nom, le type de demande auquel il s'applique et l'indicateur d'activité. Le flux lui-même — quels statuts existent et par quels chemins la demande circule entre eux — se construit dans les détails de la fiche elle-même : les statuts du workflow et les transitions, chacun avec ses règles.

La liste tourne sur le moteur standard : export de l'ensemble complet en Excel, PDF et CSV, vues enregistrées par utilisateur, choix des colonnes par écran et corbeille des éléments supprimés (?excluidas=1 dans l'URL). La recherche et le filtre fonctionnent par URL — ?q=texte et ?fd_=valeur —, ce qui permet de partager par lien le sous-ensemble exact (« les workflows actifs ») au lieu d'instructions clic par clic. Le bouton « ? » rouvre cette aide et Ctrl+K trouve n'importe quel écran par son nom.

Le dessin du flux se trouve dans deux détails de la fiche. Les STATUTS DU WORKFLOW listent les états que la demande peut avoir, avec l'ordre, la marque d'initial (où elle naît), celle de final (où elle se termine) et la visibilité pour le client. Les TRANSITIONS indiquent d'où vers où elle peut aller, avec le nom de l'action et les exigences de chaque passage : commentaire obligatoire, approbation, saisie des heures et possibilité pour le client de l'exécuter. Un statut sans transition d'arrivée est un état inaccessible — le flux ne fonctionne qu'avec les deux moitiés.

Supprimer une transition utilisée au quotidien bloque l'équipe (ticket « coincé » dans un statut). Préférez ajuster pendant les heures de faible utilisation et informez l'équipe.

Le tableau Kanban des demandes est construit à partir des workflows de cette liste : les colonnes sont les statuts du flux du type de demande. Quand aucun workflow n'est configuré, le kanban n'invente pas de colonnes — il affiche un avertissement avec un lien direct vers cet écran. Donc, si quelqu'un de l'équipe signale « le tableau est vide/sans colonnes », le diagnostic commence ici : existe-t-il un workflow pour le type ? Est-il actif ? La demande utilise-t-elle un type qui a un flux ?

Quand vous enregistrez une vue avec le bouton Vues, elle garde quatre choses : le texte de recherche, les filtres appliqués, les colonnes affichées (et leur ordre) et la colonne de tri de la liste. Appliquer la vue restaure tout d'un coup — y compris en réinitialisant le tri et la page où vous étiez, pour que le résultat soit exactement ce que la vue décrit. Les vues enregistrées avant cette version restent valables : ce qu'elles ne gardaient pas ne change tout simplement pas à l'application.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

Chaque workflow pointe vers un type de demande : c'est le flux de ce type — un bug peut suivre un chemin, une sollicitation un autre. C'est de ce lien que naît le tableau kanban : les colonnes du tableau sont les statuts du workflow du type, et le filtre de workflow du kanban change l'ensemble des colonnes affichées. Si aucun flux n'est configuré, le tableau le signale et renvoie ici. Désactiver un workflow retire le flux de la scène tout en préservant la configuration — la voie réversible quand on veut le redessiner sans perdre l'ancien dessin.

Dans le panneau d'activité de l'enregistrement, chaque note propose « Transformer en demande ». Le clic crée un ticket avec le texte de la note, son auteur et le lien vers cet enregistrement — rien n'est ressaisi. Utilisez-le quand la note est une demande d'action (« quelqu'un doit revoir ceci ») ; la note reste où elle était. Le bouton n'apparaît qu'une fois l'enregistrement sauvegardé ; une session en lecture seule (démonstration) n'en crée pas.

Ouvrez l'enregistrement et regardez la Chronologie, à droite : elle montre chaque modification sous la forme « d'une valeur à une autre », avec la personne et la date. Quand il y a beaucoup de modifications, utilisez les deux filtres en haut de la chronologie — l'un par champ, l'autre par personne. La recherche se fait dans la base, donc une modification ancienne apparaît de la même façon. Vous pouvez aussi demander à Tenkai : « qui a modifié le contrat 482 ? ».