Ich habe eine Kategorie für die Fehlerverfolgung auf unserem Discourse-Server eingerichtet. Ich möchte sowohl öffentliche Fehlermeldungen von Benutzern als auch intern eingereichte Fehler an derselben Stelle verfolgen.
Ich möchte, dass öffentliche Fehler für alle sichtbar sind (daher ist das private Thema keine Lösung). Auf diese Weise können wir Duplikate reduzieren und die Leute können einen bestehenden Beitrag kommentieren oder erläutern.
Ich möchte auch, dass unsere internen Teams Fehler einreichen können, aber ich möchte nicht, dass sie für die allgemeine Öffentlichkeit sichtbar sind, es sei denn, wir wollen das für ein bestimmtes Thema.
Wir können Whisper bei Antworten aktivieren, aber nicht beim Thema selbst. Gibt es also eine Möglichkeit, die Sichtbarkeit pro Thema festzulegen?
Das Thema auf ‘nicht aufgeführt’ zu setzen, tut fast das, was wir wollen, außer dass wir eine Gruppe von Entwicklern haben, die sie sehen müssen, aber nicht als Mods oder Admins eingestuft sind, sondern nur in einer Gruppe.
Ich möchte es so einfach wie möglich halten, da die Entwickler klug sind, aber manchmal nicht so viel gesunden Menschenverstand haben, wie ich es gerne hätte…
Können Sie zwei Versionen dieser Baumhierarchie haben? Eine für intern und eine für extern. Sie können Tags (oder Auto-Tags) verwenden, um dem internen Team zu helfen, zu sehen, welche Fehler sowohl intern als auch öffentlich auftreten.
Alternativ, wenn Sie ein Unternehmenskunde sind, könnten Sie Drittebene-Kategorien aktiviert haben.
Ich hoste es selbst, also kann ich eine weitere Ebene hinzufügen, wenn ich möchte, aber es ist wieder einmal nicht die einfachste Lösung für den Benutzer.
Was ich höre, ist, dass meine Anfrage nicht möglich ist.
Das ist schade. Dies wäre gelöst, wenn es eine Website-Einstellung gäbe für „Erlaube diesen Gruppen, nicht gelistete Themen anzuzeigen. Admins und Mods können diese Themen immer anzeigen.“
Wie wichtig ist es Ihnen, dass andere Benutzer diese Themen nicht lesen? Ich bezweifle, dass nicht gelistete Themen wirklich eine Lösung für Sie wären. Wenn Sie eine Kategorie beobachten, erhalten Sie auch eine Benachrichtigung für jedes nicht gelistete Thema, das erstellt wird. Diese Benachrichtigung enthält den Link, damit Sie das Thema besuchen und lesen können. Die Themen wären also nicht nur für die spezifische Gruppe sichtbar.
Nur Kategorien steuern den Zugriff, aber wenn Sie eine sanftere Version davon wünschen, könnten Sie etwas mit CSS tun, um etwas zu tun.
Ah. Vielleicht sollten Sie Ihre Berechtigungen so ändern, dass Entwickler (die zu dumm, zu faul oder zu nachlässig sind, um Dinge in die richtige Kategorie zu setzen) keine Erstellungsrechte in der öffentlichen Fehlerkategorie haben. Dann, wenn etwas öffentlich sein soll, kann es jemand, der genügend Aufmerksamkeit hat, um ihm zu vertrauen, in die öffentliche Kategorie verschieben.
Das würde den Zweck meiner ursprünglichen Anfrage irgendwie zunichtemachen. Ich möchte eine Fehlerkategorie und die Kontrolle über die Sichtbarkeit einzelner Themen innerhalb dieser Kategorie.
Es scheint, als sollte das machbar sein, aber basierend auf dem Feedback vielleicht doch nicht.
Ich denke, bei jedem Prozess, der „öffentlich sein könnte, privat sein könnte“ beinhaltet, gibt es jedes Mal, wenn jemand ein Thema erstellt, Spielraum für Benutzerfehler. Ob es darum geht, die richtige Kategorie auszuwählen, sich daran zu erinnern, auf „flüstern“ zu klicken oder ein Tag hinzuzufügen, das dann magische CSS-Tricks anwendet, um es zu verstecken, und so weiter. Es gibt einen Punkt, an dem Sie diese Wahl treffen müssen, und eine damit verbundene Gelegenheit, etwas falsch zu machen.
Ich denke, eine Unterkategorie ist der richtige Weg, um Vertrauen in die Sichtbarkeitsschutzmaßnahmen zu haben. Wenn Sie keine Unter-Unterkategorien dafür aktivieren möchten (oder Ihre oberste Kategorie-Struktur mit einer Alternative wie Category Groups anpassen möchten), können Sie eine zusätzliche Unterkategorie in Support für #internal-bug-reports haben und dann den Themenfilter verwenden, um eine benutzerdefinierte Themenliste zu erstellen, die Themen aus beiden Kategorien enthält, die Sie dann zum Seitenleisten für Ihre Entwickler hinzufügen können.
Nur zum Spaß habe ich getestet, ob ich den post_type eines OP über die API ändern könnte. Und obwohl es funktionierte, erschien es immer noch in der Themenliste für einen Nicht-Flüster-Testbenutzer und gab dann einen Fehler aus, wenn er darauf klickte. Es scheint also, dass zusätzliche Entwicklungsarbeit erforderlich wäre, um dies zu glätten (und es kann auch andere Konflikte für unerwartetes Verhalten geben, wenn Sie anfangen, herumzustochern).
Das ist vielleicht nicht so schlimm. Es ist mir egal, ob normale Benutzer die Titel sehen können.
Meine aktuelle Problemumgehung ist ähnlich:
Thema mit richtig beschreibendem Namen erstellen.
Der Text wird aus „Tracking-Fehler Nr.“ bestehen.
Speichern
Beitrag bearbeiten und die # aus der URL einfügen, sodass der Text jetzt „Tracking-Fehler Nr. 138“ lautet.
Alle zusätzlichen Antworten flüstern.
Jetzt füge ich einfach meine Entwicklergruppe zu den „Flüsterberechtigungen“ hinzu.
Nicht so elegant, wie ich es gerne hätte, aber das Verfassen der SOP dafür ist ziemlich einfach.
Dies hat den zusätzlichen Vorteil, dass ein normaler Benutzer einen Beitrag zum Thema hinzufügen kann, wenn er einen Fehler hat, der dem Titel ähnelt.
Es scheint also, dass zusätzliche Entwicklungsarbeit erforderlich wäre, um dies zu glätten (und es kann auch andere Konflikte für unerwartetes Verhalten geben, wenn Sie anfangen, herumzustochern).