古いトピックをぶら下げるのは悪い行動ですが、新しいトピックが見つかりませんでした。ご存知でしたら教えてください。
最近、フォーラムを多くの奇妙な目的で利用しています。
読み取り専用のカテゴリをプライベートな目的で作成し、アクセスユーザーは1人だけにする傾向があります（実際のアカウントを作成したくないすべての人にとってシンプルにするため）。時々、ユーザーがアカウントを作成し、書き込み権限も与えられます。ただし、これを実現するには、category_xyz_see と category_xyz_write のグループが必要なようです。それは単なる仕事です。
セキュリティの下にはグループしか追加できないのに、結局は別のオブジェクトであるユーザーを追加できないのは奇妙な気がします。
招待アプローチ（SSOの後ろにあるもの、おそらく今は修正されているでしょう）は試していません。
タグ付きの個人メッセージを使用して、関連するディスカッションをグループ化するという代替アプローチはどうでしょうか？
ただし、プライベートカテゴリにアクセスできる特別に作成されたユーザーを使用しています。
その理由は、今日では人々は「どこか」に別の В учетную запись を作成することを本当に望んでいないからです。そのため、短命（数か月または最長2年）の情報については、サイトの公開エリアへの読み取りアクセス権を持つ В учетную запись、または非公開カテゴリへのアクセス権を持つ特定の В учетную запись を使用しています。
このアプローチは、より多くの読者をもたらし、サイトで他の興味深いものを見つけた読者が実際のユーザーに転換する人もいるようです。
必須の В учетную запись はサイトをきれいに保ちます。
これは、誰かが Discourse をどのように使用しているかのユースケースシナリオとしてのみ記述しています。それ以上ではありません。開発者として、私は人々が私が予見しなかったことをするときに興味を持つことがよくあります。
しかし、これは必要なユーザーを追加する別のグループを追加することで解決できるため、大したことではありません。
もし考えてみれば、PMの定義は個別のアクセス制御を持つトピックです。UIのさまざまな場所に表示されますが、両方を持つと非常に混乱するでしょう。
これは興味深いアイデアだと思います。一般的に、私たちはグループのユーザーへの同等性を求めてきました。これが逆のケースを見るのは初めてです。
非常に小さなサイトや、ほんの一握りの人を対象としたカテゴリの場合、グループ名の横にあるカテゴリのセキュリティフィールドにユーザー名を入力できると、非常に便利で迅速になると思います。しかし、明らかに、多くのユーザー名を追加し始めると、扱いにくくなります。
スティーブンとは意見が異なります。少なくともプログラマーの視点からは。ユーザーがいるかグループがいるかは関係ありません。どちらもオブジェクトです。私の見解では、両者は互いにマッピングされ、重複する可能性があります。
UIで混乱を招くでしょうか？おそらく。そうならないかもしれません。重複を表示する必要はありません。ユーザーがグループにも存在することは（システムが解決すべきことなので）関係ありません。
また、サブカテゴリは親カテゴリレベルでアクセス権を持つ必要があるという制限にも遭遇しました。これはある意味理にかなっています。全体を逆転させることもできると思いますが、この特定のケースでは逆のように感じるでしょう。
実際のユースケースをもう一度示します。なぜそうするのかを説明するのがはるかに簡単です。適切な英語の単語をすべて知らないかもしれませんが、人々は要点を理解してくれると思います。
人が亡くなり、多くの人が遺産に関わっています。
アクセスを容易にするために読み取り専用ユーザーを作成しました（そのユーザーを「表示グループ」に追加しました）。
サイトにすでにいる一部の人々もグループに追加されました（ログアウトしてアカウントを切り替える必要がないように）。
最上位カテゴリには、共通の情報（埋葬など）が含まれています。
1つのサブカテゴリには、金銭情報が含まれています（まだ不明なため、すべての問題が解決するまで全員に公開されません）。ここに信頼できる男性（遺産外の人でもよい）を追加しても、最上位カテゴリへのアクセスが必要（またはアクセスすべき）であることを意味しません。
少し考えれば、それを処理する良い方法を思いつくことができると確信しています。しかし、基本的に、単一のユーザーを任意のレベルに追加できるようにすることが、より美しく（そして論理的に）解決します。
そして、これらすべては追加のグループを使用してほぼ達成可能なので、おそらく労力に見合う価値はありません。
グループとカテゴリの概念はDiscourseに組み込まれており、多くのことに影響するため、この変更に対する意欲があるかどうかはわかりません。これは大きな変更になります。
とはいえ、これは常にDiscourseの設定や管理を複雑に見せる分野であり、Yahooグループやメーリングリストのような従来のシステムと比較してもそうであることに同意します。
すでに特別な扱いを受ける特別なグループがいくつかあります。例えば、信頼レベル、全員、モデレーター/管理者などです。もしかしたら、カテゴリのセキュリティ設定から直接、バックエンドでカテゴリへのアクセスにのみ使用される特別なグループの作成を許可することもできるかもしれません。例えば次のようになります。
カテゴリfooの場合：
foo_see、foo_reply、foo_createグループを作成し、ユーザーを追加するfoo_moderatorグループを作成することも許可するfooアクセスグループは、/groupsページからは表示されず、コンポーザーで@で提案されることもないfooアクセスグループは特定のfooカテゴリに紐付けられ、他のカテゴリへのアクセスには使用できないfooのサブカテゴリは、現在の混乱を招く循環エラー処理の代わりに、自動的にfooへのアクセス権を付与される可能性があるこの方法の良い点は、カテゴリを表示したときに、そのカテゴリへのアクセス権を持つすべてのユーザーの名前と、表示、返信、作成のアクセス権を持つユーザーを表示するUIも公開できることです。これは常にギャップだと感じていました。現在、プログラム的に提供している情報は、カテゴリが保護されていることを示す:lock:だけで、誰がアクセス権を持っているかはわかりません。
この機能をカテゴリ設定内に配置することで、カテゴリとグループの作成方法も簡素化されます。これにより、より多くのユーザーが保護されたカテゴリを作成・管理できるようになります。サイト管理者とともに、カテゴリへのアクセスを管理できるユーザーのためにfoo_ownerグループさえも作成できるかもしれません。
これがどのように見えるかはわかりませんが、このような変更に対する意欲がない可能性もありますが、私たちは常にブレインストーミングや新しいアイデアを歓迎します。可能であればモックアップも歓迎します！
興味深いですね。それでも少し複雑に感じます（既存のものの上に構築されているため、やむを得ないのかもしれません）。
グループはすでに肥大化しているように感じます（誰が何に属しているのか常にわからなくなる - はい、命名が悪いことは承知しています）。そのため、foo タイプのアプローチは主にカテゴリから見えるようにすべきかもしれません。少なくとも、デフォルトでグループに表示するかどうかのチェックボックスが必要です。
残念ながら、Discourse は私が全く知らないツールで構築されています。せいぜい、データベースに直接アクセスするユーティリティを作成するくらいでしょう。いずれにせよ、他の人々はスクリプトでよりうまくやっているようです。まあ、退職したらできるかもしれません :)。