Staff カテゴリ内で管理者（モデレーターも同様）のサブカテゴリを作成しようとすると、以下のようなメッセージが表示されます。
「サブカテゴリへのアクセスが許可されているグループは、親カテゴリへのアクセスも許可されている必要があります。以下のグループはサブカテゴリのいずれかにはアクセスできますが、親カテゴリにはアクセスできません：管理者」
しかし、
ご意見をお聞かせください。
[編集：試しに、管理者専用のカテゴリを作成しようとした際に表示される実際のラベルのスクリーンショットを撮ってみました。
少しおかしいのですが、(a) 管理者は Staff のサブカテゴリへのアクセス権を持っていること、また (b) 管理者はどこへでも移動できるため、デフォルトで任意のカテゴリへのアクセス権を持っていることです。
もちろん、Staff のセキュリティセクションを編集して、管理者とモデレーターを親カテゴリに明示的に追加することはできません。]
pfaffman
(Jay Pfaffman)
3
作成したサブカテゴリがスタッフのみに公開されていることを確認する必要があります。あなたは全員がアクセスできるサブカテゴリを作成しようとしましたが、その際の権限設定に気づかず、そのためこの事実は真実ではないと考えています。
Canapin
(Coin-coin le Canapin)
4
私がそう思ったからこそ削除したメッセージですが、エラーメッセージをもう一度お読みください：
「サブカテゴリへのアクセスが許可されているグループは、親カテゴリへのアクセスも許可されている必要があります。以下のグループはサブカテゴリのいずれかへのアクセス権を持っていますが、親カテゴリへのアクセス権はありません：モデレーター。」
そのため試してみましたが、同じ問題に直面しました。
セキュリティを「モデレーター：表示/投稿/作成可能」と設定してサブカテゴリを作成しようとしましたが、同じエラーメッセージが表示されます。ただし、モデレーターは「スタッフ」に含まれるはずであり、親カテゴリのセキュリティは「スタッフ：読み取り/投稿/作成可能」と設定されています。
pfaffman
(Jay Pfaffman)
5
バグのようですが、なぜ管理者ではなくモデレーターが太陽カテゴリを読めるようにしないのでしょうか？
Canapin
(Coin-coin le Canapin)
6
起こっていることは、権限が機能単位ではなく、グループ単位で設定されているためです。
モデレーターは、スタッフグループとモデレーターグループの両方に所属しています。
しかし、もしスタッフカテゴリーがあり、その下にモデレーター用サブカテゴリーがあった場合、モデレーターグループにのみ所属している人はどうなるでしょうか？その人はサブカテゴリーにはアクセスできても、親カテゴリーにはアクセスできません。Discourse はそのような状態を許可していません。
理論的には、モデレーターだけがアクセスできるサブカテゴリーを作りたい場合、親カテゴリーのセキュリティ設定に「モデレーター：閲覧・投稿・作成可能」を追加するべきですが、デフォルトのスタッフ用サブカテゴリーではそれができません。
また、それは無意味でもあります。なぜなら、「スタッフ」とはモデレーターと管理者を指し、管理者はすべてのカテゴリーにアクセスできるからです。
Heliosurge
(Dan DeMontmorency)
7
誰かが確認する必要があります。しかし、推測すると、モデレーター権限を持たずにモデレーターグループにユーザーを追加できるかもしれません。
一方、スタッフになるには、モデレーターまたは管理者の権限が必要です。
はい。しかし、私たちはそのようにしました。「全員」の権限などを削除し、サブカテゴリにアクセスできるグループを「管理者」または「モデレーター」のいずれかに限定しました。しかし、機能しません。
以前は可能でしたし、権限のルールに基づけば可能であるはずです。
私もそう思います。
プライバシーやその他の問題により、管理者のみが閲覧できるトピックが存在します。そのため、管理者専用のサブカテゴリが必要です。
モデレーター用のサブカテゴリは利便性のためのもので、モデレーター関連の議論を特定のエリアにまとめるためのものです。管理者は最初からすべてを見られるため、ラベルを「モデレーター」向けに付けつつ、実際にはスタッフ全体が利用できるようにすれば、その問題は解決します。これは問題の半分を解決する手段ですが、もちろん、実際には「手抜き」に近い方法です。
しかし、残りの半分は解決できません。元の投稿を編集して、管理者向けであることを反映させます。
それは誤りです。モデレーターはスタッフカテゴリにアクセスできます。したがって、モデレーター（または管理者）用のサブカテゴリを設けることは、Discourse によって（あるいは設けるべきです）許可されています。ルールは、サブカテゴリにアクセスできるグループは、必ず親カテゴリにもアクセスできなければならないというものです。
しかし、管理者専用のサブカテゴリを設けることは全く無意味ではありません。なぜなら、モデレーターは管理者が見られるすべての情報を見られるわけではないからです。
Canapin
(Coin-coin le Canapin)
11
私のメッセージをもう一度よくお読みください。システムが設計されている通り、この挙動は正常であり、あなたが遭遇したエラーは当然のものです。フォーラムへのアクセス権はグループのみに依存します。
Discourse によって自動的に作成されるデフォルトのスタッフカテゴリは、Staff グループのみが利用可能です。
Moderators グループ用にサブカテゴリを作成しようとしても、親カテゴリが Staff グループ（Moderators グループではない）にのみ利用可能なため、機能しません。
モデレーターが親カテゴリにアクセスできる唯一の理由は、彼らも Staff グループに所属しているからです。
「moderation」という名前のサブカテゴリを作成し、セキュリティ設定を「staff can read/post/reply」に設定することは可能です。これなら問題なく動作します。
はい、無駄になります。また、Administrators グループにのみカテゴリやサブカテゴリを公開することも、問題なく可能です。
明確に申し上げますと、私もこれが問題の原因だと考えています。当初は説明として言及しようかと思いましたが、そのままとすることにしました。
しかし、その場合、これは「制定された規則が、その規則を生み出した理由を反映していない」という、厄介なバグの典型例です。モデレーターも管理者もスタッフの一部であることは明白であり、その理由からすれば、彼らが「Staff」カテゴリ内にサブカテゴリを設けられるべきであるはずです。
実際、数年前には、管理者専用、あるいは「単に」モデレーター専用のサブカテゴリを「Staff」内に作成することが可能でした。これは明らかに適切な対応でした。
なぜ管理者専用のサブカテゴリが無意味だと考えられるのでしょうか？
「Staff」カテゴリではできません。上記のスクリーンショットをご覧ください。
Canapin
(Coin-coin le Canapin)
13
おっしゃる通り、無意味ではないという意味でした。
はい、その通りですね。
これらのサブカテゴリを作成したい場合は、「ニューススタッフ」親カテゴリを作成し、セキュリティ設定を「管理者、スタッフ、モデレーターが閲覧/投稿/作成可能」に設定するのが良いと思います。
Heliosurge
(Dan DeMontmorency)
14
なぜ、言及されているように新しいカテゴリを作成しないのでしょうか？ スタッフは特殊なグループです。
私は複数のグループにユーザーを追加できます。あるユーザーがグループBに属し、かつグループAにも属しているからといって、グループAのカテゴリへのアクセス権が自動的にグループBにも付与されるわけではありません。ただし、信頼レベルに基づくカテゴリ権限は最小限のレベルで機能します。
私にはわかりませんが、おそらくスタッフ権限を編集して、モデレーターグループに直接アクセスを許可できるはずです。
Stephen
(Stephen)
15
Discourse には階層的な権限という概念はありません。Staff は管理者とモデレーターを含む特別なグループです。サブカテゴリは、親カテゴリに存在しないグループを指定できませんし、Staff グループの ACL は固定されています。スタッフカテゴリには次のように記載されています。
警告: このカテゴリは事前に設定されたカテゴリであり、セキュリティ設定は編集できません。このカテゴリを使用しない場合は、流用するのではなく削除してください。
これはバグではありません。単に、デフォルトのスタッフカテゴリには適さないユースケースを持っているだけです。異なることを望むこと自体に問題はありませんが、組み込みのカテゴリを異なる目的で使えないからといって、それがバグであると言い張るのは誤りです。
あなたはこのカテゴリをそのまま使いたくないのは明白です。管理者とモデレーターがアクセス可能な新しい親カテゴリを作成し、その下にそれぞれのサブカテゴリを分けて作成することも可能です。
riking
(Kane York)
16
これは、カテゴリ権限警告システムの極めて軽微なバグです。システムが staff が admins と moderators の合計と等しいことを認識していないためです。
12 もの投稿で議論を繰り返す価値はありません。
回避策として、親カテゴリの許可グループに admins と moderators を明示的に追加してください。ただし、moderators サブカテゴリには、依然として admins がアクセスできる点にご注意ください。
はい。ただし、モデレーターは管理者用サブカテゴリにはアクセスできません。
一般的なケースではその通りですが、自動作成され権限の変更ができない Staff カテゴリではそれが不可能です。これが質問の主題でした。(a) Staff カテゴリはすべてのインストールで自動的に作成され、(b) ユーザビリティの観点からカテゴリ数を制限することが重要であり、(c) Staff カテゴリは以前は正常に動作していたため、これは不合理な要求だとは思いません。
私の提案は簡単な解決策です。現在、Staff カテゴリを自動作成する際、以下の権限が設定されています（変更は不可能）：
staff は作成・返信・閲覧が可能
代わりに、Staff カテゴリを自動作成する際には、Discourse が以下の権限を設定すべきです：
staff は作成・返信・閲覧が可能
admins は作成・返信・閲覧が可能
moderators は作成・返信・閲覧が可能
この簡単な修正により、このバグが解決され、追加の不要なカテゴリを作成する必要もなくなり、Staff カテゴリは以前のように正常に動作するようになります。
Stephen
(Stephen)
18
あなたの指摘は逆だと思います。既存のカテゴリを変更するよりも、目的に特化したカテゴリを作成する方が圧倒的に簡単です。特に、すでに既存の権限設定で運用されている数千のインストールが存在する状況では、なおさらです。
実際、私の解決策を注意深く読んでいただければ、それが後方互換性を維持し、以前のインストールが以前と同じように動作し続けることに気づくはずです。
Stephen
(Stephen)
20
しかし、これは後方互換性とは何の関係もありません。このトピックでは、変更を推進しているのはあなただけです。あなたが提案していることは、依然として開発時間が必要であり、テストが必要であり、メンテナンスも必要です。既存の設定で動作しているインストールが数千件あるということは、現状のままでも問題ない管理者・モデレーションチームも数千件あるということです。
このトピックは数ヶ月前に作成されました。4 月にすでにこの「正しい」方法を実装できたはずです。なぜ CDCK が、7 年間このように機能してきたソフトウェアの変更を、たった 1 サイトのために資金提供すると期待するのでしょうか？あなた自身が最も簡単な設定変更をする気がないなら、なぜ誰かが何らかの行動を取るべきなのでしょうか？あなたのガイダンスに従わない姿勢は、他の誰かが行動を起こす動機になりません。
スタッフカテゴリに特別なことは何もありません。数ヶ月前に提案されたように、適切な権限を持つ別のカテゴリを作成すれば、問題は解決します。
上記のいずれの方法よりも、コミュニティで小さな変更を実装する方がはるかに簡単です。
それが「最も適切な方法」ではありませんが、4 月には実装していました。通常、バグの修正や機能の実装を待ってから自社の準備を整えることはしません。
はい、はい、そしていいえです。私は長年ソフトウェア開発者およびマネージャーとして働いており、バグを修正するために何が必要かはよく理解しています。この修正には数分間の開発時間、数時間のテスト時間、そして現在のバージョンと同じ以上のメンテナンスは不要です。
あなたの主張は、新しいものを開発する意味が全くないということになりますね。Discourse は現状のままでも数千のチームが利用しているのに、なぜさらに 1 時間でも開発に費やす必要があるのでしょうか？議論する際は論理的に考えてください。
これは根拠のない無意味な失礼な推測でした。上記の私のコメントからも明らかな通りです。
実際、それは誤りです。以前は異なる、そしてより優れた方法で動作していました。以下は、管理サブカテゴリとモデレーターサブカテゴリを許可するネイティブのスタッフカテゴリを持つ、4〜5 年前に作成された既存のホスト型 Discourse システムの例です：
この論点は私のシステムとは関係ありません。私が動作させるために変更を必要としているわけではありません。重要なのは、すべての Discourse システムに付属するスタッフカテゴリが、本来可能だったもの、そして以前にあったものよりも機能が劣っているということです。Discourse がスタッフカテゴリを自動作成する手間をかけるなら、なぜそれをうまく、そしてクリーンに設計しないのでしょうか？私はシンプルで実装が容易な提案をしており、複数のスタッフカテゴリを扱う私たちにとって有用な機能を回復させるものです。チームはこの提案を検討する自由がありますし、そうでない自由もあります。
riking
(Kane York)
22
警告：このカテゴリは事前設定済みカテゴリであり、セキュリティ設定は編集できません。このカテゴリを使用しない場合は、流用するのではなく削除してください。
スタッフカテゴリを再作成して、トピックを新しいカテゴリに移動すればよいでしょうか？
