Tags
Eine Tag-Bibliothek pro Projekt. Jeder Roadmap-Eintrag?, Kommentar, Release, jede Triage-Nachricht und Rückfrage kann Tags tragen. Ein neuer Tag ist einen Tastendruck entfernt.
Eine Tag-Bibliothek
Tags gehören zum Projekt. Öffne Einstellungen → Tags, um die Bibliothek zu sehen: Jeder Tag ist eine Zeile mit Namen, Farbe und der Anzahl der Stellen, an denen er gerade hängt.
Tags gelten pro Projekt; projektübergreifend werden sie nicht geteilt. Jede Roadmap hat ihr eigenes Vokabular, und die Trennung verhindert, dass alte Tags aus einem Produkt in ein anderes rutschen.
Passt an alles
Das Tag-Modell ist polymorph: Derselbe Tag kann an jeder dieser Stellen hängen, ohne eigenes Schema pro Art:
- Roadmap-Einträge: erscheinen als Chips auf den Board-Karten und im Eintrags-Dialog.
- Kommentare: markiere eingehende Kommentare bei der Moderation als spam, support, feature-wunsch.
- Releases: markiere sicherheit, breaking, beta, damit Leser nach Art überfliegen können.
- Feedback (Triage): markiere duplikat, info-fehlt, bevor eine Nachricht übernommen wird.
- Rückfragen: operative Tags wie dringend, vom-gründer.
Löschst du einen Tag, verschwindet er überall. Löschst du einen Eintrag, werden seine Tags gelöst, bleiben aber in der Bibliothek.
Beim Tippen anlegen
Die Tag-Auswahl setzt auf Autovervollständigung. Tipp los, und vorhandene Tags werden gefiltert. Drück Enter bei einem Namen, den es noch nicht gibt, und ein Chip wird angelegt wird vorgemerkt. Beim Speichern werden vorhandene Tags angehängt und neue in einem Schritt angelegt.
Brichst du die Auswahl ab, werden vorgemerkte Tags verworfen: Nichts landet in der Bibliothek, bis du speicherst.
Normalisierte Namen
"Frontend", "frontend" und " Frontend " ergeben alle denselben Tag. Die Auswahl bietet kein „‚frontend‘ anlegen“ an, wenn es Frontend schon gibt.
Angezeigt wird der Name, wie er zuerst getippt wurde; spätere Suchen schreiben ihn nicht um. Umbenennen geht ausdrücklich in der Tag-Bibliothek.
In der öffentlichen Roadmap-API
Tags von Roadmap-Einträgen sind in der öffentlichen Roadmap-API enthalten, damit du Chips auf deinen eigenen Roadmap-Seiten zeigen kannst: bug, verbesserung, area/auth. Die Sichtbarkeit folgt dem Eintrag: Ist er öffentlich, sind es seine Tags auch.
Tags an Kommentaren, Triage-Nachrichten und Rückfragen sind nur für Admins und erscheinen auf keiner öffentlichen Seite.
Tags aus deiner App
Feedback kann schon mit Tags ankommen. Das Widget, dein Backend oder eine App senden Tag-Namen mit der Nachricht, und ein Live-Schlüssel akzeptiert nur die Tags, die du für ihn erlaubst (Projekteinstellungen → API-Schlüssel → Bearbeiten → Tags, die dieser Schlüssel setzen darf). Ein privater Schlüssel darf jeden Tag setzen. Das Senden eines Tags legt ihn nie an, und ein nicht erlaubter Tag lehnt die ganze Nachricht mit 422 ab, damit Fehler schon beim Entwickeln auffallen.
Einen Tag zu erlauben macht ihn nicht öffentlich: Tags an Feedback bleiben nur für Admins. Die API-Anleitung führt durch die Einrichtung.
Feedback filtern
Der Filter Tag in der Feedback-Liste zeigt Nachrichten mit einem der gewählten Tags. Er lässt sich mit den anderen Filtern kombinieren, und die API nimmt dasselbe als ?tag=bug,crash.
Tag-API
Ein einziger Endpunkt hängt Tags an alle Arten von Einträgen an oder ersetzt sie:
PUT /api/v1/projects/{project_id}/{entity_kind}/{entity_id}/tags
{
"tag_ids": ["01HX...", "01HX..."],
"names": ["frontend", "needs-design"]
}entity_kind ist eines von umbrella, comment, release, feedback und follow_up. Der Body ersetzt alle Tags des Eintrags. names werden normalisiert, dedupliziert und per finden-oder-anlegen aufgelöst.
Für Autovervollständigung ruf GET /api/v1/projects/{project_id}/tags?q=fro auf: zuerst Treffer am Anfang, dann Treffer im Wort, höchstens 50.