一度使用したフラグは編集できません

現在、フラグは作成後に編集することはできません。

フラグが使用された後に、それらを削除したり、意味を変更したりすることはできないはずだと理解しています。

カスタムフラグの編集は計画されているが、まだ実装されていないということでしょうか?

Webインターフェイスにこのオプションを追加する必要があります。

明確にするために、これが移動されたので。編集のことではありませんでした。しかし、コンソールレールを使用せずに自動非表示をトリガーするフラグを設定するオプションのことでした。

カスタムフラグの現在の設計では、作成後に編集することも可能です。ただし、一度使用されると編集できなくなります。無効にして別のフラグに置き換えることはできます。

フラグ編集ページには、次のような注意書きがあります。

カスタムフラグは、一度使用されると、編集または削除することはできず、無効にすることしかできません。

さらに編集が許可されない理由を詳しく教えていただけますか?

説明の変更(明確化のためなど)は、動作に悪影響を与えるべきではありません。

投票に似ている可能性が高い

この種の問題については、2つの異なる見方があるようです。a) 歴史を変えない b) 動作するまでハック(改善)する。

一貫性についてです。現時点ではこの動作を変更する計画はありません。したがって、カスタムフラグが使用された後に変更を加える必要がある場合は、プロンプトの指示に従ってフラグを無効にし、新しいフラグを作成する必要があります。

ほとんどのサイトではフラグを変更する必要はありません。変更が必要な場合でも、使用開始後にフラグが大きく変更されることはほとんどありません。

承知いたしました。コンソールを使用してテキストを適応させます。

ユーザーの教育を目的として、「個人情報共有」というフラグを使用します。これは、ユーザーがメッセージの作成者に連絡したい場合に、公開(主にメール)で回答するためではなく、その連絡を仲介するために使用します。

このプロセスでは、テキストを適応させる必要があります。

しかし、

フラグ理由の50件という制限はそれほど多くありません。

フラグを選択した後に詳細を追加するオプションを使用するのはどうですか?「その他の項目」フラグと同様に。

そうなると、フラグ付けによってフォーラムを個人的なメッセージから解放するのを手伝っているすべての人が、無知なユーザーのために教育的なテキストを書く必要が出てきますが、それは起こりません。

それがオープンソースの力です! :fire:

もちろん、そうすると自分で対応する必要があり、私たちからのサポートを得ることが難しくなる可能性があります。しかし、それはすでにわかっていることですね。一度使用されたフラグは、コンソールで変更するのではなく、無効にして新しいフラグを作成することをお勧めします。

これは単なる隠し設定であり、増やすことができます。ホスティングをご利用のお客様で、その制限に達している場合は、私たちに連絡していただければ増やすことができます。また、お客様がカスタムフラグをどのように使用しているか、そしてなぜそれほど多くの変更を行う必要があるのかを知ることも、私たちにとって興味深いことです!

プラグインか何かでカスタムフラグ機能を拡張する必要があるようですね。

そうでなければ、モデレーターがプライベートメッセージ(PM)を送信する追加作業を伴うテンプレートプラグインかもしれません。

あるいは、PM用のカスタム自動化スクリプトという代替案もありますか?

この制限は、より具体的なルールを設けたいが、それらのルールについて知識がない視聴者にも開放的な状態を維持したい、というより高度な公開プロジェクトのワークフローにおいて、Discourse ソフトウェアの利用をかなり制限していると思います。

適切な説明と関連するヘルプ記事へのリンクを備えたカスタムフラグは、現在のフォーラムの期待値やルールをユーザーに伝える最も簡単な方法です。大量のルールが列挙された別々のドキュメントとは異なり、フラグの説明は、まさに必要とされるタイミングで、必要とする人々(フラグを設定する人々と、フラグを受け取る人々の両方)に見えるように表示されます。私の見るところ、フラグは Discourse の超能力です。

例えば、私たちのケースでは、フォーラムの特定の領域ではオフトピックとみなされるものの定義がはるかに厳格であるため、ユーザーにそれを明確に伝える必要があります。一般的な「オフトピック」フラグだけでは不十分です。(基本的に、現在「オフトピック」ラベル付きのシステムフラグを使用するたびに、「でもこれはオフトピックじゃない」という返信がトリガーされ、なぜこの特定の制約下でオフトピックなのかについて個人的な会話が必要になっています。)

私は、そのケースのために適切な説明とワークフローのドキュメントへのリンクを備えた、具体的な「ワークフローに適合しない」フラグを作成します。フラグの説明は、基盤となるワークフローの進化に伴って進化する必要があるため、フラグ上のメッセージングを反復し、調整していきます。

しかし、編集を許可されていないため、タイポを修正するだけでもできません。より詳細な説明を追加することなどは論外です。


「履歴を変更しない」という懸念は理解できますが、それを回避する方法はあります。例えば、説明フィールドのみを編集可能にする、新しい編集可能な「ドキュメント/ヘルプ」フィールドを追加する、フラグに新しいバージョンフィールドを追加して編集時にそれを増やし、投稿が以前のバージョンのフラグでフラグ付けされたことが視覚的にわかるようにする、などです。


追記:50個のフラグという制限は、無効化されたフラグもカウントに含まれますか?もしそうであり、無効化されたフラグを削除も編集もできない場合、フラグは長期的なセットアップにとって持続可能ではない、限られた非再生可能資源になってしまいます。