グループオーナーは必ずしもグループメンバーである必要はない

On my site I have a use case for people being given the privilege of managing group membership without being a member of the group themselves. I assumed this is how it worked and was surprised to see that someone I added as group manager is now also a group member.

The use case? We use groups to assign badges. And to give access to private categories. And the people responsible for doing this are not always group members.

Edit: having noticed this, I then removed some group owners only to realize they are still group members. Seems to me these should be managed independently.

「いいね!」 15

We ran into this problem this week, too. (Although our groups represent a “group” membership outside of Discourse, too.) But that membership is not decided by a member of the group, and not by a Discourse admin, either.

「いいね!」 5

Just ran into this very problem, where a group’s membership is not administered by a member of the group.

Our use case

We want a handful of non-Discourse-admins to be able to manage group membership for several groups without becoming members of those groups themselves.

Extra credit

This is probably asking too much, but I thought I’d throw it in… it’d be awesome if a group could be named as admin of another group (i.e., membership of the @bar group can be managed by any member of the @foo group). This would allow us to have a “group managers” group containing our non-Discourse-admins in charge of managing other groups’ memberships. :slightly_smiling:

「いいね!」 5

I just moved this to the #feature:voting category as I’d like it to be thrown into the mix for voting when that starts happening.

I like this idea! There is one person in charge of managing internal groups in my community but does not need to have admin privileges. It would be helpful to be able to set up a group for this so we can easily add/remove people to help her.

Another related feature that would be needed is the ability for group owners to see and manage the group even when “Group is visible to all users” is deselected. There should also be the option to allow group members, or members of a specific other group, to see the group.

「いいね!」 1

Sure, I am open to disconnecting the two permissions.

「いいね!」 7

Any chance the goal of “group owner does not need to be group member” with stretch goal of “group can be named as owner of another group” would be suitable for a GSoC project?

「いいね!」 2

Very unlikely, way too small of a job.

Group can be owner of another group is not even something I would be comfortable adding.

Did anything come from the OPs request to separate group membership & group ownership? @sam supported the idea a while back (above).

Scenario: We added a moderator to a group, to manage group membership. However, this resulted in him getting the group’s badge displayed on his avatar.

「いいね!」 3

Thanks for the reply, @Biscuit! I just came across this again in my community and the issue persists. In fact, it’s becoming a bit of a problem because certain leaders in my community complain that they are not trusted to properly manage the groups they are charged with managing. They have to ask an admin to add/remove people. I’m trying to keep down the number of admins (a conversation for another day).

It’s pr-welcome so the discourse team have indicated they are open to having it done as a community contribution. Any takers?

It appears to me that with the new front-end groups management interface, there is no obvious place to list owners who are not members. Perhaps the answer is simply to just list them at the top, with the Owner badge but not the date added, posted or seen. And/or to list with a highlight color, as on staff posts?

Then the functionality to add owners could be a + ADD OWNERS button next to the existing + ADD MEMBERS button. Selecting this would pop up a modal to add one or more owners. On the list, if the REMOVE MEMBER button is selected and the member is an owner, the user would remain on the list as an owner but not as a member. If REMOVE AS OWNER is selected, the user would remain as a member but no longer as an owner (unless the user is not already a member and was only listed as an owner, in which case the user would be removed from the list entirely).

Unannotated screenshot for illustration.

「いいね!」 5

We have the use case that there should be one master group that manages many smaller groups (~30 / i.e. @Archangels manage local Angel communities). They should not have to be members of all 30 groups, just be able to add/remove members.

「いいね!」 3

We also run into this each time Google Summer of Code comes around. It also seems related to the various ideas about hierarchical/sub-groups, too.

「いいね!」 3

はい、こんにちは。私もこの問題を抱えており、それが引き起こす質問の例をいくつか挙げさせていただきます。少し厄介です。グループの作成者およびオーナーとして、デフォルトのグループマネージャーは私、管理者でなければならず、他の誰かを任命することはできません。なぜなら、自分で作成したグループをその人が管理する理由がないからです。グループメンバーとグループ管理者がいるべきですが、管理者は私の意見では、自動的にそのグループのメンバーである必要はありません。これが私のケースで生じる問題です。

エキスパートカテゴリプラグインを使用しています。そのため、特定のエキスパートグループにカテゴリを割り当てました。残念ながら、私はこのグループのエキスパートとして自動的に見なされますが、これは全く良くありません。なぜなら、新しいトピックを投稿するとき、私はそのグループのテーマのエキスパートではないのに、エキスパートとして貢献していると表示されるからです。うまく説明できているか分かりませんが。:grin:

こんにちは、パトリック!この機能リクエストは正当だと思いますが、ユースケースがよく理解できません。

エキスパートカテゴリプラグインではグループオーナーが必要ですか?それ以外の場合は、オーナーなしでグループを作成できます。

グループへの参加リクエストを許可する機能には、グループオーナーが必要です。

ユーザーが自分で専門家だと判断するのではなく、メンバーになるためにリクエストする必要があるという文脈では、理にかなっていると思います。@support-explorers グループでも同様のことを行っていますよね?

@patrickemin 昨年、グループのメンバーに追加されるのを回避するのに役立つバグを報告しました。ただし、その場合メッセージは届かないため、グループのリクエストタブに新しいリクエストがないか頻繁に確認するワークフローを見つける必要があります。
ただし、メンバーシップリクエストを有効にした後、自分自身をグループから削除することは可能です。

「いいね!」 4

@moinさん、ありがとうございます!Discourseに関する知識の豊富さにはいつも感心させられます。:clap:

「ユーザーが参加リクエストを送信できるようにする」設定を有効にするためにグループオーナーが必要な理由を考えていたのですが、理にかなっていると思いました。誰かがグループに参加リクエストをしたときに、すべてのモデレーターに通知する必要がある状況は避けたいでしょう。したがって、この場合、グループオーナーがグループのメンバーではないことも可能にしたいと思うでしょう。

「いいね!」 4

私の意見では、グループへの参加リクエストは、もしあればグループオーナーだけでなく、管理者にも送信されるというのが、かなり簡単な解決策でしょう。そうすれば、グループオーナーがいなくても管理者は引き続き通知を受け取ることができ、グループオーナーまたはグループのメンバーである必要がなくなります。

グループをオーナーとして追加できるようにすると良いでしょう。これにより、オーナー/メンバーのみではなく、階層化されたグループが可能になります。グループをオーナーとして追加することで、管理者、オーナー、メンバーといった階層化されたグループが実現できます。ただし、技術的には両方のグループに属することになるため、管理グループのカテゴリ/アクセス権を継承する際の注意点があるかもしれません。

「一括オーナー追加」を試してみたいのですが、機関にとっては便利かもしれません。

このトピックを振り返ってみると、グループを一括追加として選択するのは最善ではないことに気づきました。

同期された場合に問題が発生し、原因と結果を特定するのが難しいかもしれません。

まあ、すでにカテゴリモデレーターのようなグループオーナーがいます。私は手動でそのようなことを行っています。

グループがグループを管理できるようにすることは、管理者が不要なオーナーの追加/削除を容易にします。オーナーグループには、通常のメンバーを追加/削除できる独自のコアオーナーがいます。

ダンさん、ありがとうございます。カテゴリモデレーターがそのカテゴリに関連付けられたグループを所有できるというあなたの指摘は、非常に共感できます。これは、1つのグループが別のグループを管理できる、より柔軟な管理者構造を想定されているように思われます。これにより、権限とワークフローを大幅に合理化できる可能性があります。

現在、Discourseでは個々のユーザーのみがグループオーナーになれます。しかし、特に構造化されたコミュニティ(学校、部署、チームなど)のような実際のユースケースでは、次のようなことをしたい場合がよくあります。

  • 「グループA(例:mentor-coordinators)がグループB(例:mentors)を管理できる」
  • 「…ただし、AのメンバーがBに追加されたり、そのバッジ/IDを継承したりすることなく」

これにより、次が可能になります。

  • ID(グループメンバーシップ)と制御(グループオーナーシップ)のクリーンな分離
  • サイト全体の管理者権限やモデレーター権限を与えることなく、メンバーシップ管理(招待/削除/承認)の委任
  • ポスティンググループを制御するグループにカテゴリのモデレーションを関連付ける機能

グループオーナーシップがユーザー名だけでなく、他のグループも受け入れられるモデルを指しているように思われます。このアイデアは、いくつかの過去のスレッドと一致しています。

これがどのように機能するか、興味があります。

  • 管理グループに所属している場合、UIはオーナーシップの継承を表示しますか?
  • グループオーナーは、すべてのグループ設定を編集できますか、それともメンバーシップのみを管理できますか?
  • これはカテゴリ権限とペアにしたり、グループのカテゴリに自動リンクしたりできますか?

このアイデアを強く支持します。さらに発展させていくのを見たいです。

「いいね!」 2