Derzeit dürfen Flags nach der Erstellung nicht mehr bearbeitet werden.
Ich verstehe, dass sie nicht gelöscht oder ihre Bedeutung geändert werden können, nachdem sie verwendet wurden.
Ist die Bearbeitung von benutzerdefinierten Flags geplant, aber noch nicht implementiert?
Diese Option muss definitiv zur Weboberfläche hinzugefügt werden.
Um es klarzustellen, da dies verschoben wurde. Ich bezog mich nicht auf Bearbeiten. Aber die Option, dass ein Flag automatisch ausgeblendet wird, ohne die Konsolen-Rails zu verwenden.
Die Art und Weise, wie benutzerdefinierte Flags derzeit konzipiert sind, ist es immer noch möglich, sie zu bearbeiten, nachdem sie erstellt wurden. Sobald sie jedoch verwendet wurden, können sie nicht mehr bearbeitet werden. Aber sie können deaktiviert und durch ein anderes Flag ersetzt werden.
Auf der Seite zur Bearbeitung von Flags gibt es einen entsprechenden Hinweis:
Sobald ein benutzerdefiniertes Flag verwendet wurde, kann es nur deaktiviert, aber nicht bearbeitet oder gelöscht werden.
Könnten Sie näher erläutern, warum eine weitere Bearbeitung nicht zulässig ist?
Das Ändern der Beschreibung (z. B. zur Klärung) sollte kein Verhalten beeinträchtigen.
Wahrscheinlich ähnlich wie die Abstimmung
Es scheint, dass es zwei verschiedene Ansichten zu dieser Art von Problemen gibt: a) Geschichte nicht ändern b) Lasst uns sie hacken (verbessern), bis sie funktioniert.
Es geht um Konsistenz. Derzeit gibt es keinen Plan, dieses Verhalten zu ändern. Wenn Sie also eine Änderung an einem Ihrer benutzerdefinierten Flags vornehmen müssen, nachdem es verwendet wurde, sollten Sie den Anweisungen in dieser Aufforderung folgen, das Flag zu deaktivieren und ein neues zu erstellen.
Die meisten Websites müssen überhaupt keine Änderungen an den Flags vornehmen - und für diejenigen, die dies tun, wird nicht erwartet, dass sie sich viel ändern, wenn überhaupt, sobald sie verwendet werden.
Ok. Ich werde die Konsole verwenden, um den Text anzupassen.
Wir verwenden ein Flag namens „shares private information“, während wir Benutzer aufklären, nicht öffentlich (hauptsächlich per E-Mail) zu antworten, wenn sie einen Autor einer Nachricht erreichen möchten.
In diesem Prozess müssen wir Texte anpassen.
Aber für
ist die Grenze von 50 Flag-Gründen nicht sehr hoch.
Was ist mit der Option, zusätzliche Details hinzuzufügen, nachdem eine Flagge ausgewählt wurde? Ähnlich wie bei der Option „Etwas anderes“?
Dann müsste jede Person, die dazu beiträgt, das Forum durch Markieren von persönlichen Nachrichten frei zu halten, den Bildungstext für den ungebildeten Benutzer schreiben, was nicht passieren wird.
Das ist die Macht von Open Source! 
Aber natürlich bist du dann auf dich allein gestellt und es kann schwieriger für dich werden, Unterstützung von uns zu erhalten. Aber das weißt du ja schon. Wir empfehlen, Flags zu deaktivieren und neue zu erstellen, anstatt sie über die Konsole zu ändern, sobald sie verwendet wurden.
Dies ist nur eine versteckte Einstellung und kann erhöht werden. Kunden auf unserem Hosting, die an diese Grenze stoßen, können sich an uns wenden, um sie für sie zu erhöhen. Es wird auch für uns interessant sein, von Kunden zu hören, wie sie die benutzerdefinierten Flags verwenden und warum sie möglicherweise so viele Änderungen vornehmen müssen!
Klingt, als ob Sie dann vielleicht ein Plugin oder so etwas benötigen, um benutzerdefinierte Markierungen zu erweitern.
Andernfalls vielleicht ein Vorlagen-Plugin mit zusätzlicher Arbeit, bei der ein Moderator eine PM sendet…
Oder alternativ vielleicht ein benutzerdefiniertes Automatisierungsskript, vielleicht für eine PM?
Ich finde, diese Einschränkung ist ziemlich limitierend, wenn man die Discourse-Software in fortgeschritteneren öffentlichen Projektworkflows einsetzen möchte, in denen man spezifischere Regeln haben will, aber dennoch offen für ein Publikum bleiben möchte, das sich mit diesen Regeln nicht auskennt.
Benutzerdefinierte Flags mit angemessenen Beschreibungen und Links zu relevanten Hilfeartikeln sind derzeit der einfachste Weg, um den Nutzern die Erwartungen und Regeln des aktuellen Forums mitzuteilen. Im Gegensatz zu separaten Dokumentationen mit einer langen Liste von Regeln ist die Flag-Beschreibung genau dann sichtbar, wenn sie benötigt wird, und genau für diejenigen, die sie brauchen – sowohl für die Personen, die die Flag setzen, als auch für diejenigen, die sie erhalten. Flags sind aus meiner Sicht die Superkraft von Discourse.
Zum Beispiel müssen wir in unserem Fall Nutzern klar machen, dass in einigen Bereichen des Forums die Definition, was als Off-Topic gilt, viel strenger ist, und dass die generische Off-Topic-Flag dafür nicht ausreicht. (Im Grunde löst derzeit jede Nutzung der Systemflag mit dem Label „Off-Topic“ eine Antwort aus – „aber das ist kein Off-Topic“ – und wir müssen ein persönliches Gespräch darüber führen, warum es unter diesen spezifischen Einschränkungen als Off-Topic gilt.)
Ich würde die spezifische Flag „Passt nicht zum Workflow“ mit einer angemessenen Beschreibung für diesen Fall und einem Link zur Workflow-Dokumentation erstellen. Ich würde die Botschaft auf der Flag iterativ anpassen und maßschneidern, da die Beschreibung sich zusammen mit der Entwicklung des zugrunde liegenden Workflows weiterentwickeln muss.
Aber da du es nicht erlaubst, sie zu bearbeiten, kann ich nicht einmal einen Tippfehler korrigieren, geschweige denn ausführlichere Erklärungen hinzufügen.
Ich verstehe die Sorge, „die Geschichte nicht zu ändern“, aber es gibt Wege, dies zu umgehen: Zum Beispiel nur das Beschreibungsfeld bearbeitbar machen; oder ein neues bearbeitbares „Dokumentation/Hilfe“-Feld hinzufügen; oder ein neues Versionsfeld zur Flag hinzufügen und es bei Bearbeitungen erhöhen, sodass sichtbar ist, dass der Beitrag mit einer früheren Version der Flag markiert wurde … usw.
P.S. Zählt die Begrenzung auf 50 Flags auch die deaktivierten Flags? Wenn ja, und ich kann weder inaktivierte Flags löschen noch bearbeiten, dann ist Flags eine begrenzte, nicht erneuerbare Ressource, die für jede langfristige Einrichtung nicht nachhaltig ist.
Es sieht so aus, als ob dies in 3.5.0beta3 durch FEATURE: allow edit custom flags - Pull Request #32344 - discourse/discourse - GitHub irgendwie, sozusagen, vielleicht verbessert wurde, aber ich sehe keine Verbesserung — nicht einmal bei Flags, die wir noch nie verwendet haben.
Vor der Einführung der Funktion für benutzerdefinierte Flags haben wir mit site_texts fröhlich die Bedeutung einiger eingebauter Flags geändert 
… Ich verstehe die Begründung, aber diese Einschränkung wirkt ziemlich väterlich.