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).
У нас есть следующий сценарий использования: должна существовать одна главная группа, управляющая множеством меньших групп (~30, например, @Archangels управляют локальными сообществами Angel). Им не обязательно быть участниками всех 30 групп — достаточно возможности добавлять и удалять участников.
Мы также сталкиваемся с этим каждый раз, когда приходит Google Summer of Code. Это также, похоже, связано с различными идеями о иерархических/подгруппах.
Да, здравствуйте, у меня тоже возникла эта проблема, и я приведу пример вопросов, которые она вызывает и которые немного раздражают. Как создатель и владелец группы, по умолчанию должен быть назначен менеджер группы — то есть я, администратор, — и я не могу назначить кого-то другого. Ведь нет смысла, чтобы кто-то другой управлял группой, которую создал я сам. Должны быть участники группы и администратор группы, но, на мой взгляд, администратор не обязан автоматически быть участником этой группы. Вот проблема, которую это создаёт в моём случае.
Я использую плагин категории экспертов. Я назначил определённые категории группе экспертов. К сожалению, я автоматически считается экспертом в этой группе, что совершенно неприемлемо, потому что когда я создаю новую тему, система указывает, что я вношу вклад как эксперт, хотя я вообще не являюсь экспертом по тематике этой группы. Не знаю, понятно ли я объясняю.
Привет, Патрик! Хотя я по-прежнему считаю, что этот запрос на новую функцию обоснован, я не до конца понимаю твой сценарий использования.
Обязаны ли владельцы групп быть указаны согласно Discourse Category Experts? В противном случае можно создавать группы без владельцев, и тогда ты сможешь управлять составом группы как администратор, не входя в неё сам.
Для функции, позволяющей пользователям запрашивать вступление в группу, необходимы владельцы группы.
Мне кажется логичным, что пользователи должны запрашивать вступление в группу, а не сами решать, что они являются экспертами. Вы ведь делаете что-то подобное с группой @support-explorers, верно?
@patrickemin В прошлом году я сообщил об ошибке, которая могла бы помочь вам избежать добавления в группу как участника. Однако вам потребуется настроить рабочий процесс, чтобы регулярно проверять наличие новых запросов во вкладке «Запросы» группы, так как в этом случае вы не будете получать уведомления.
Тем не менее, можно выйти из группы после включения запросов на вступление:
Спасибо, @moin! Я всегда впечатляюсь тем, насколько хорошо вы разбираетесь в Discourse.
Я как раз обдумывал логику, почему для включения настройки «Разрешить пользователям отправлять запросы на вступление» требуется владелец группы, и это имеет смысл. Не хотелось бы оказаться в ситуации, когда при каждом запросе на вступление в группу нужно уведомлять всех модераторов. Так что да, в этом случае также должно быть возможно, чтобы владелец группы не состоял в ней.
На мой взгляд, довольно простое решение заключалось бы в том, чтобы запросы на вступление в группу отправлялись не только владельцу группы (если он есть), но и администратору. Таким образом, если владельца группы нет, администратор всё равно получит уведомление и не обязательно должен быть владельцем группы или её участником.
Хорошим вариантом было бы разрешить добавлять Группу в качестве владельцев. Это позволило бы создать иерархию групп с уровнями, а не ограничиваться только ролями владелец/участник, которые вы знаете: при добавлении группы в качестве владельцев появятся Администраторы, Владельцы и Участники. Однако есть один нюанс: наследование управляемых групповых категорий/доступов может привести к тому, что пользователь технически окажется в обеих группах.
На самом деле у нас уже есть своего рода владелец группы — это модераторы категорий. Я делаю что-то подобное вручную.
Возможность управлять группой через другую группу означает, что добавлять или удалять владельцев станет проще без необходимости участия администратора. У группы «Владельцы группы» есть свои основные владельцы, которые могут добавлять или удалять обычных участников в группе владельцев.
Спасибо, Дэн — ваша мысль о том, что модераторы категорий могут владеть группой, привязанной к их категории, действительно находит отклик. Похоже, вы представляете более гибкую структуру администрирования, где одна группа может управлять другой группой, и это могло бы значительно упростить настройку прав и рабочих процессов.
В настоящее время Discourse позволяет назначать владельцами групп только отдельных пользователей. Однако в реальных сценариях использования, особенно в структурированных сообществах (например, в школах, отделах или командах), мы часто хотим иметь возможность сказать:
«Группа A (например, mentor-coordinators) может управлять группой B (например, mentors)»
…без того, чтобы участники группы A добавлялись в группу B или наследовали её значок/идентичность
Это позволило бы:
Четко разделить идентичность (членство в группе) и контроль (владение группой)
Передать делегирование управления членством (приглашение/удаление/одобрение) без предоставления прав администратора или модератора всего сайта
Привязать модерацию категории к группе, которая управляет группой, отвечающей за публикации в этой категории
Кажется, вы предлагаете модель, в которой владение группой допускает не только имена пользователей, но и другие группы. Эта идея перекликается с несколькими более старыми темами:
