Tags

Une bibliothèque de tags

Les tags vivent au niveau du projet. Ouvrez Paramètres → Tags pour voir la bibliothèque : chaque tag est une ligne avec un nom, une pastille de couleur et le nombre d'éléments qui l'utilisent.

Les tags sont propres à chaque projet ; ils ne se partagent pas entre projets. Chaque roadmap a son vocabulaire, et les garder séparés évite que de vieux tags d'un produit débordent sur un autre.

S'applique à tout

Le modèle de tags est polymorphe : le même tag peut se poser sur chacune de ces surfaces sans schéma propre à chaque type :

• Éléments de roadmap: affichés en pastilles sur les cartes du tableau et dans la fenêtre de l'élément.
• Commentaires: marquez les commentaires spam, support, demande-de-fonctionnalité pendant la modération.
• Versions: marquez sécurité, breaking, bêta pour que les lecteurs parcourent par type.
• Retours (tri): marquez doublon, infos-manquantes avant de promouvoir un message.
• Questions de suivi: tags opérationnels comme urgent, envoyé-par-le-fondateur.

Supprimer un tag le retire partout où il était posé. Supprimer un élément détache ses tags, mais les laisse dans la bibliothèque.

Créer en tapant

Le sélecteur de tags fonctionne d'abord par autocomplétion. Tapez : les tags existants se filtrent au fur et à mesure. Appuyez sur Entrée sur un nom qui n'existe pas encore et une pastille sera créé est préparée. À l'enregistrement, les tags existants sont attachés et les nouveaux créés en un seul aller-retour.

Annuler le sélecteur abandonne les créations préparées : rien n'entre dans la bibliothèque avant l'enregistrement.

Normalisation des noms

"Frontend", "frontend" et " Frontend " renvoient tous au même tag. Le sélecteur ne propose pas « Créer « frontend » » quand Frontend existe déjà.

Le nom affiché est celui tapé en premier ; les recherches suivantes ne le réécrivent pas. Pour renommer, faites-le dans la bibliothèque de tags.

Dans l'API publique de la roadmap

Les tags des éléments de roadmap sont inclus dans l'API publique, pour afficher des pastilles sur vos propres pages de roadmap : bug, amélioration, area/auth. La visibilité d'un tag suit celle de l'élément : si l'élément est public, ses tags le sont aussi.

Les tags des commentaires, des messages du tri et des questions de suivi sont réservés aux admins et n'apparaissent sur aucune page publique.

Tags depuis votre app

Un retour peut arriver déjà tagué. Le widget, votre backend ou une app envoient des noms de tags avec le message, et une clé live n'accepte que les tags que vous autorisez dessus (Paramètres du projet → Clés d'API → Modifier → Tags que cette clé peut définir). Une clé privée peut définir n'importe quel tag. Envoyer un tag ne le crée jamais, et un tag non autorisé fait refuser tout le message avec une 422, pour que les erreurs se voient pendant le développement.

Autoriser un tag ne le rend pas public : les tags des retours restent réservés aux admins. Le guide de l'API détaille la configuration.

Filtrer les retours

Le filtre Tag de la liste Feedback affiche les messages portant l'un des tags choisis. Il se combine aux autres filtres, et l'API accepte la même chose avec ?tag=bug,crash.

API des tags

Un seul endpoint gère l'ajout et le remplacement pour tous les types d'éléments :

PUT /api/v1/projects/{project_id}/{entity_kind}/{entity_id}/tags

{
  "tag_ids": ["01HX...", "01HX..."],
  "names":   ["frontend", "needs-design"]
}

entity_kind vaut umbrella, comment, release, feedback ou follow_up. Le corps remplace l'ensemble des tags de l'élément. Les names sont normalisés, dédoublonnés et résolus en trouver-ou-créer.

Pour l'autocomplétion, appelez GET /api/v1/projects/{project_id}/tags?q=fro, d'abord ceux qui commencent par le texte, puis ceux qui le contiennent, 50 au maximum.