すべての自動グループの可視性設定を尊重する

[mdoggydog]

（ある人にとっては機能リクエストでも、別の人にとってはバグ報告です… ）

「グループ」インデックスページ（例：/groups または /g）は、自動グループの可視性設定を尊重し、それに応じて表示するべきです。これは Moderators グループでは行われていますが、他のグループでは行われていません。これは GroupsController.index() 内のハードコードされた例外によるもので、非スタッフユーザーが表示した場合、可視性設定に関係なく、他の自動グループがインデックスページに決して表示されない原因となっています。

この例外的な動作は、少なくとも2つの点で問題があります。

1. 管理者が非スタッフユーザーのために自動グループをインデックス表示したい場合、これがそれを妨げます。
2. 可視性設定と実際の可視性との乖離は、危険なほど混乱を招きます。特に、設定が自動グループでは無視される/無関係であるかのように見えます（例：「自動グループは、この設定をどうしてもスタッフ専用であるようだ…」）、たとえその設定が特定のグループページ（例：/g/trust_level_0）とそのメンバーリストへのアクセスを引き続き制御しているとしてもです。

関連コード内のコメントは、この例外的な動作が「ページを整理するために、すべての非スタッフから自動グループを隠す」ことを意図していることを示しています。しかし、それを達成するためにこのメカニズムは必要ありません。インデックスページを整理したい管理者は、他のグループと同様に、自動グループの可視性を自由に設定できます。

この動作を実装している app/controllers/groups_controller.rb の6行のコードを単純に削除することを提案します。

もし「Discourseの新規インストールでは」デフォルトで「整理された」インデックスが重要だと考えられるのであれば、より良いメカニズムは、システムによって最初に作成されたときに自動グループの可視性設定を単純にスタッフ専用にデフォルト設定することです。非スタッフユーザーのインデックスページでデフォルトのフィルターを「非自動」に設定することです。

（可視性設定はアクセス制御です。インデックスページがどのように見えるかに関係なく、デフォルト値は適切なデフォルトアクセスレベルを構成するものでなければなりません。）

参考までに、このトピックは以下の議論のフォローアップです。

How does visibility of automatic groups work?

I’m a bit confused as to how the visibility of automatic groups works. At this point, I am just talking about the /groups directory. Here is what I am seeing in a pretty fresh install of 2.7.0.beta4: If an user with admin or moderator bits looks at /groups, they see all 8 automatic groups (admins, moderators, staff, trust_level_[0-4]). If a non-admin, non-moderator user (no matter the trust_level) looks at /groups, they see only the moderators group. But, all of these groups have the same, …

[simon]

@mdoggydog

表示設定と実際の表示との間の乖離は、危険なほど混乱を招きます。

通常のユーザーとしては、散らかった表示ではない方が好ましいです。信頼レベルグループは私には関係がないように思えます。しかし、現在の動作方法が奇妙であることにも同意します。特に次の点を考慮すると：

@mdoggydog

設定は、特定のグループページ（例：「/g/trust_level_0」）とそのメンバーリストへのアクセスを引き続き制御しますが。

信頼レベルグループページが有用であれば、URLを知らなくてもUIからアクセスできる方法があるはずです。

@mdoggydog

Discourse の新規インストールでデフォルトで「散らかった表示ではない」インデックスにするのが重要だと考えられる場合、より良いメカニズムは、システムによって自動的に作成されたときに、自動グループの可視性設定を単にスタッフのみにデフォルト設定することです。

それは理にかなっています。信頼レベルグループの可視性を制限することが、何かを壊さないようにするために、いくつかの注意が必要かもしれません。現在、イベントを作成するユーザーにTL0グループが表示されない場合、公開イベントを作成することはできません。これに似た他のケースがあるかどうかはわかりません。

[RGJ (Richard - Communiteq)]

管理者以外でもフィルターのドロップダウンで「自動グループ」を利用できるようにする。
デフォルトのフィルター（管理者と一般ユーザーの両方）で自動グループを除外する。
/g/trust_level_0?asc=true が /g?type=automatic と同じ承認ロジックを使用するようにする（現在は前者は機能するが、後者は「表示可能なグループはありません」と表示される）。

追加のリクエスト：/admin 経由で /g にアクセスすると、管理メニューバーが突然消えます。これは煩わしいと思います。管理者が /g にアクセスした場合に、そのページにメニューバーを追加するのはどうでしょうか。

[Moin]

@RGJ

追加リクエスト：/g に /admin 経由でアクセスすると、管理メニューバーが突然消えます

UX に関するトピックがあります Groups Tab in Admin Inconsistent With Other Tabs で議論されています

[mdoggydog]

@simon

それは理にかなっています。トラストレベルグループの可視性を制限しても何も壊れないように、注意が必要な場合があります。

はい、「当たり前」というやつですね…。元の提案をこれに合わせて編集しました。「可視性」はアクセス制御であり、そのように扱われるべきです（つまり、UIの外観を調整するために制御がねじ曲げられるのではなく、UIは制御の状態を透過的に反映するはずです）。

@RGJ

では、これは次のように簡単に解決できるのではないでしょうか。

• 管理者以外にも「自動グループ」をフィルターのドロップダウンで利用できるようにする？
• デフォルトのフィルター（管理者と一般ユーザーの両方）で自動グループを除外する？

その通りです！「自動」がスタッフ以外のフィルターのドロップダウンで利用できないことに気づきませんでした。（それは、自動グループを非表示にするのと同じ6行のコードブロックによって省略されています。したがって、そのコードを削除すれば、それも修正されます。）

バックエンドコードはすでに「非自動」フィルターを定義していますが、フィルターのドロップダウンでは誰にも（スタッフかどうかにかかわらず）提供されていないようです。

[tobiaseigen]

@mdoggydog

• 管理者が非スタッフユーザー向けの自動グループをインデックス化したい場合、それはできません。

「非スタッフユーザー向けの自動グループをインデックス化する」とは、非スタッフユーザーが自動グループフィルターにアクセスしてそれらを表示できるようにすることを意味しますか？

@mdoggydog

表示設定と実際の表示の間の断絶は、危険なほど混乱を招きます。

これは正当な懸念です。管理者のエクスペリエンスをよりシンプルで一貫性のあるものにしようとしており、これは人々を混乱させる可能性のある領域です。この特定のケースについては他の苦情は聞いていませんが、動作が一貫するように修正することの価値は理解できます。

@mdoggydog

app/controllers/groups_controller.rb からこの動作を実装している6行のコードを単純に削除することを提案します。

もし、Discourse の新規インストールでデフォルトで「煩雑でない」インデックスをデフォルトにすることが重要だと考えられているのであれば、より良いメカニズムは、システムによって自動グループが最初に作成されたときに、それらの自動グループの可視性設定をスタッフのみにデフォルト設定することです。

これら2つの項目は理にかなっているように思われます。しかし、これを行う前に、自動グループの表示設定を変更することによる意図しない結果はありますか？

@RGJ

では、これは次のように簡単に解決されませんか？

• 「自動グループ」を非管理者向けのフィルタードロップダウンで利用可能にする？
• デフォルトのフィルター（管理者と一般ユーザーの両方）が自動グループを除外するようにする
• /g/trust_level_0?asc=true が /g?type=automatic と同じ承認ロジックを使用するようにする（現在は前者は機能するが、後者は「表示可能なグループはありません」と表示される）

これはToDoリストとして良さそうです。このようにまとめてくれてありがとう。

[mdoggydog]

@tobiaseigen

@mdoggydog

• If an admin wants to index automatic groups for non-staff users, this prevents them from doing that.

When you say “index automatic groups for non-staff users”, do you mean allow non-staff users to be able to access the automatic groups filter and see them?

In that quoted text, I specifically mean “show automatic groups on the /g index page when viewed by non-staff users”. Regardless of the filter setting, the automatic groups (except for “Moderators”) are currently not allowed to be listed on the /g index page for non-staff users.

In a later post (the one preceding this one), I additionally advocate for providing the “Automatic Groups” option in the filter dropdown for all users, not just stafff users. I don’t think there is a good reason to hide it from non-staff users. (Note that no matter what is presented in the dropdown menu, the filter is still available to any user who can type the correct keyword into the URL bar.)

@tobiaseigen

@mdoggydog

I suggest simply removing the 6 lines of code from app/controllers/groups_controller.rb that implements this behavior.

If it is considered important to default to a “de-cluttered” index for new installations of Discourse, then a better mechanism would be to simply default to staff-only visibility settings for the automatic groups when they are first created by the system.

These two items seem to make sense. However, before we do this are there any unintended consequences of changing the visibility settings for automatic groups?

Please note that I edited my suggestion for default de-cluttering prior to your post; you have quoted the original version. The revised/current text from my first post is (with the strikeouts removed for brevity):

@mdoggydog

If it is considered that important to default to a “de-cluttered” index, then a better mechanism would be to set the default filter on the index page to “non-automatic” for non-staff users.

(The visibility setting is an access control — the default value should be whatever constitutes a sane default level of access, regardless of what the index page looks like.)

[tobiaseigen]

現在、新しいサイトでのユーザーリストは以下のようになっています。

自分の言葉で要約すると、リクエストは /g のグループディレクトリを次のように変更することです。

1. メンバーに自動グループフィルターも表示する
2. フィルターが選択されたときに、すべての自動グループをメンバーに表示する
3. /g のデフォルトビューから自動グループを除外する

(3) はメンバーだけでなく、全員に適用されるべきだと感じています。管理者がメンバーとほぼ同じ体験をできるようにし、混乱を減らすことが目標の1つです。

この変更を行うことで、メンバーがアクセスできるが、現在URLを知る必要がある自動グループの存在をUIで明示することになります。

管理者向け：

メンバー向け：

[mdoggydog]

@tobiaseigen

要約すると、リクエストは /g のグループディレクトリを次のように変更することです。

1. メンバーにも自動グループフィルターを表示する
2. フィルターが選択されている場合に、すべての自動グループをメンバーに表示する
3. /g のデフォルトビューから自動グループを除外する

変更点と優先順位を少し変えて、再構成します。

A. 非スタッフユーザーのために、インデックスから自動グループを削除するのをやめる
B. 非スタッフユーザーのために、「自動グループ」フィルターをドロップダウンメニューから削除するのをやめる
C. すべてのユーザーに、ドロップダウンメニューで「非自動グループ」フィルターを提供する
D. /g でデフォルトで「非自動グループ」フィルターを有効にする

CとDの私の言い方は、3と比較して意図的です。UIは、どのフィルターが有効になっているかについて非常に透明であるべきだと思います。フィルターが選択されていない場合は、UIはフィルターされていないビュー、つまりユーザーが表示/アクセスできるすべてのグループを表示するはずです。

3を「フィルターが選択されていない場合、non_automaticフィルターを静かに使用する」と解釈することもできますが、それでも混乱を招くと思います。フィルターが選択されていない場合は、フィルターを適用しないだけでよいはずです。逆に、フィルターが適用されている場合は、名前を付けてユーザーにわかるようにする必要があります。

さらに詳しく見ていくと、フィルター選択の問題の一部は、「グループタイプでフィルター」というヒントが、フィルターが選択されていないメニュー項目のラベルに押し込められている方法から生じています。最終的には、フィルターが選択されていない項目を「すべてのグループ」とラベル付けする方が明確になると思います。次に、「非自動グループ」という追加の項目を追加し、どちらの項目をデフォルトにするかは自由に決められます。これにより、（a）ユーザーがフィルターされたビューを受け取っていることが明確になり、（b）フィルターされていないビューに切り替える方法が明確になります。

私に言わせれば、フィルターメニュー項目は次のようにラベル付けされます。

• すべてのグループ
• 私が所属するグループ （私のグループは曖昧なため）
• 私が所有するグループ
• 公開グループ
• プライベートグループ （クローズドは「シャットダウン」または「使用されなくなった」ように聞こえるため）
• 自動グループ
• 非自動グループ

そして、__テキストボックス__のヒント文字列を「すべてのグループ」から「グループ名でフィルター」に変更します。

さらに…プルダウンメニューとテキストボックスの順序を入れ替えます！

[tobiaseigen]

この件についてご協力いただきありがとうございます。現時点では、グループリストのUXに大きな変更を加える可能性は低いと考えていますが、少なくともグループリストの機能をすべての人で同じように使えるようにするというアイデアは気に入っています。

@mdoggydog

もし私なら、フィルターメニュー項目を次のようにラベル付けします。

• すべてのグループ
• 私が所属するグループ （「私のグループ」は曖昧なため）
• 私が所有するグループ
• 公開グループ
• プライベートグループ （「クローズド」は「停止」または「使用されていない」ように聞こえるため）
• 自動グループ
• 非自動グループ

これらはすべて良い提案ですが、「自動」と「非自動」という言葉は、やや不格好で技術的すぎ、あまり意味をなさないように感じます。自動グループは、人々が獲得または付与された特権に関するものであるため、それを反映するようなラベルを考え出すことはできないでしょうか？

[almereyda (jon r)]

まさに同じことを考えていました。「パブリック＋非公開グループ」と呼ばれるものにデフォルトビューを設定し、そのようなオプションを導入するのが良いと思います。「私が所有するグループ」が実際に意味することや、「非公開グループ」がもはやアクティブではないように聞こえる可能性のある曖昧さをなくすことも理にかなっています。

@mdoggydog

• Automatic Groups
• Non-Automatic Groups

これらは次のようなものに似ています。

• システムグループ
• ユーザーグループ、「パブリック＆プライベートグループ」、または単にグループ

このフィルター項で提供されるグループの順序を設定できるかもしれません。最初の項目は常にデフォルトビューとなり、選択できるようになります。そうでなければ、すべての人に機能する適切なデフォルト順序を見つけること、またはこれらのビューのいずれかをデフォルトにすること、は別の問題になります。

また、「自動/システムグループ」に人間が読める名前のエイリアスを付けることができるかもしれません。たとえば、一部の言語では、通常のグループのフルネームフィールドのように、先頭に大文字を使用することを好みます。また、オプションで適切なデフォルトの説明テキストを提供することで、サイト管理者が管理メニューを通じて説明を選択しない場合、それらが「技術的」に見えにくくなる可能性があります。

「自動」グループと「非自動」グループの間に、アイコンやボックスを薄い灰色で塗りつぶすなど、何らかの視覚的な区別があるかもしれません。

[tobiaseigen]

システムグループが好きです！

[simon]

「自動」は、実装の詳細、つまりユーザーがグループに自動的に追加されることを指しているように聞こえます。通常のユーザーの観点からは、あまり意味がないと思います。厳密には正確でもありません。ユーザーはスタッフグループに自動的に追加されるわけではありません。おそらく、自動グループの最も正確な名前は「事前シードグループ」ですが、それはひどい名前です。

「システム」グループは悪くないように聞こえますが、自動グループを「信頼レベル」と「スタッフ」に分割するのはどうでしょうか？グループタイプのフィルターは次のようになります。

• 私のグループ
• 私が所有するグループ
• 公開グループ
• 非公開グループ
• 信頼レベル
• スタッフ

必要に応じて、信頼レベルグループがグループページに表示されるかどうかを決定する trust level groups public のようなサイト設定がある可能性があります。

[tobiaseigen]

サイトスタッフを分離するのは良い考えです。人々は実際にモデレーターや管理者のリストをここで見つけることを評価するかもしれません。そうでなければ、/about に行く必要があることを知っておく必要があります。

[mdoggydog]

再度コメントします…「システム/自動グループを除くすべてを表示」フィルターをあまり必要としないディスコースのユーザー/管理者のグループに私も含めてください。これらのグループの存在は、それほど気にならないようです。

いずれにしても、私の優先事項は、真の「すべてのグループ」フィルター（フィルターなし）を利用できるようにすることであり、私自身の好みは、シンプルに保ち、それを /groups ページのデフォルトにすることです。