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.
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.
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.
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.
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?
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.
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).
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.
네, 안녕하세요. 저도 같은 문제를 겪고 있으며, 이 문제가 몇 가지 다소 성가신 질문을 불러일으키고 있으니 예를 들어보겠습니다.
그룹 생성자이자 소유자로서는 기본적으로 그룹 관리자가 한 명은 있어야 하는데, 그 사람은 저(관리자)여야 합니다. 다른 사람을 임명할 수 없죠. 제가 직접 만든 그룹을 왜 다른 사람이 관리해야 하는지 이유가 없기 때문입니다. 그룹에는 일반 멤버와 그룹 관리자가 있어야 하지만, 제 생각에는 관리자가 반드시 해당 그룹의 멤버일 필요는 없습니다. 제 경우에서 이 문제가 일으키는 문제는 다음과 같습니다.
저는 전문가 카테고리 플러그인을 사용하고 있습니다. 그래서 특정 카테고리를 전문가 그룹에 지정해 두었죠. 그런데 저는 자동으로 이 그룹의 전문가로 간주되고 있는데, 이는 전혀 좋지 않습니다. 새로운 주제를 게시할 때, 저는 이 그룹의 주제에 대해 전혀 전문가가 아니지만 전문가로서 기여하고 있다고 표시되기 때문입니다. 제 설명이 잘 전달되고 있는지 모르겠네요.
@patrickemin 저는 작년 버그를 보고한 적이 있는데, 이 버그를 통해 그룹 멤버로 추가되는 것을 피할 수 있을 것입니다. 하지만 이 경우 해당 메시지가 수신되지 않으므로, 그룹의 요청 탭에서 새로운 요청이 있는지 자주 확인하는 워크플로우를 설정해야 합니다.
가입 요청을 활성화한 후에도 그룹에서 자신을 제외할 수 있습니다:
방금 “사용자가 가입 요청을 보낼 수 있음” 설정을 활성화하려면 그룹 소유자가 필수인 이유를 곰곰이 생각해 봤는데, 충분히 납득이 됩니다. 누군가가 그룹 가입을 요청할 때마다 모든 모더레이터에게 알림이 가길 원하지는 않을 테니까요. 그래서 이 경우에도 그룹 소유자가 그룹 멤버가 아니어도 되도록 하는 것이 좋습니다.
제 생각에는, 그룹 가입 요청을 그룹 소유자가 있는 경우 소유자에게만 보내는 것이 아니라, 관리자에게도 함께 보내는 것이 상당히 간단한 해결책이 될 수 있습니다. 이렇게 하면 그룹 소유자가 없는 경우에도 관리자가 여전히 알림을 받게 되며, 관리자가 그룹 소유자이거나 그룹 멤버일 필요가 없어집니다.
좋은 방법 중 하나는 그룹을 소유자로 추가할 수 있도록 허용하는 것입니다. 이렇게 하면 단순히 소유자/멤버만 있는 구조 대신, 소유자로 그룹을 추가함으로써 관리자, 소유자, 멤버로 이루어진 계층형 그룹 구조를 만들 수 있습니다. 다만 한 가지 주의할 점은, 관리되는 그룹의 카테고리/액세스가 기술적으로 두 그룹 모두에 속하게 될 수 있다는 것입니다.
사실 우리는 이미 일종의 그룹 소유자로서 카테고리 관리자(Category moderators)를 보유하고 있습니다. 저는 이런 일을 수동으로 처리합니다.
그룹이 다른 그룹을 관리할 수 있게 되면, 관리자의 개입 없이 소유자를 추가하거나 제거하는 것이 더 쉬워집니다. 그룹 소유자 그룹(Group Owners Group)에는 일반 멤버를 소유자 그룹에 추가하거나 제거할 수 있는 자체 핵심 소유자(core owners)가 있기 때문입니다.
Dan, 감사합니다 — 카테고리 관리자가 자신의 카테고리와 연결된 그룹을 소유할 수 있다는 점이 정말 공감됩니다. 하나의 그룹이 다른 그룹을 관리할 수 있는 더 유연한 관리자 구조를 상상하시는 것 같고, 이는 권한과 워크플로우를 간소화하는 데 큰 도움이 될 수 있습니다.
현재 Discourse는 개별 사용자만 그룹 소유자로 설정할 수 있습니다. 하지만 학교, 부서, 팀과 같은 구조화된 커뮤니티를 포함한 실제 사용 사례에서는 종종 다음과 같은 기능을 원합니다:
“A 그룹(예: mentor-coordinators)이 B 그룹(예: mentors)을 관리할 수 있다”
…A의 구성원이 B에 추가되거나 B의 배지/신원을 상속받지 않는 상태에서
이를 통해 다음이 가능해집니다:
신원(그룹 멤버십)과 통제(그룹 소유권) 간의 명확한 분리
사이트 전체 관리자나 관리자 권한을 부여하지 않고 멤버십 관리(초대/제거/승인) 위임
게시 권한이 있는 그룹과 해당 카테고리의 관리를 연결할 수 있는 기능
그룹 소유권이 단순히 사용자 이름뿐만 아니라 다른 그룹도 허용하는 모델로 나아가고 계신 것 같습니다. 이 아이디어는 몇몇 오래된 스레드와도 일치합니다:
