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.
Sim, olá, eu também tenho esse problema e darei um exemplo das perguntas que ele levanta, que são um pouco irritantes. Como criador e proprietário do grupo, deve haver um gerente de grupo padrão, que sou eu, o administrador, e não posso nomear outra pessoa. Porque não há razão para essa pessoa gerenciar um grupo que eu mesmo criei. Deveria haver membros do grupo e um administrador do grupo, mas o administrador não precisa, na minha opinião, ser automaticamente um membro desse grupo. Aqui está o problema que isso representa no meu caso.
Eu uso o plugin de categoria de especialista. Portanto, atribuí certas categorias a um grupo de especialistas. Infelizmente, sou automaticamente considerado um especialista neste grupo, o que não é nada bom, porque quando posto um novo tópico, diz que estou contribuindo como especialista quando não sou especialista no tema deste grupo. Bem, não sei se estou me fazendo entender.
Você precisa de proprietários de grupo para o recurso que permite aos usuários solicitar associação ao grupo.
Acho que faz sentido no contexto de que os usuários precisam solicitar para se tornarem membros e não decidir que são especialistas por conta própria. Acho que você faz algo semelhante com o grupo @support-explorers, não é?
@patrickemin Relatei um bug no ano passado que pode ajudá-lo a evitar ser adicionado como membro do grupo. Mas você precisaria encontrar um fluxo de trabalho para verificar com frequência se há novas solicitações na aba de solicitações do grupo, porque você não receberá as mensagens nesse caso.
Mas é possível se remover do grupo após habilitar as solicitações de associação:
Obrigado @moin! Fico sempre impressionado com o quanto você sabe sobre o Discourse.
Eu estava apenas pensando sobre a lógica pela qual um proprietário de grupo é necessário para que a configuração “Permitir que usuários enviem solicitações de associação” seja ativada e isso faz sentido para mim. Você não gostaria de estar em uma situação em que todos os moderadores tivessem que ser notificados quando alguém solicitasse a entrada em um grupo. Portanto, sim, neste caso, você também gostaria que fosse possível para o proprietário do grupo não ser um membro do grupo.
Na minha opinião, uma solução bastante simples seria que os pedidos para entrar num grupo fossem enviados não apenas para o proprietário do grupo, se houver um, mas também para o administrador. Dessa forma, se não houver proprietário do grupo, o administrador ainda seria notificado e não precisaria ser o proprietário do grupo nem um membro do grupo.
Uma boa opção seria permitir a adição de um Grupo como proprietários. Isso permitiria grupos hierárquicos com níveis em vez de ter apenas proprietário/membro, como você sabe, ao adicionar um grupo como proprietários - Administrador(es), Proprietários e membros. Uma ressalva, no entanto, pode ser a herança de grupos gerenciados com acesso, sendo tecnicamente em ambos os grupos.
Bem, já temos um “dono” de grupo, de certa forma, com os moderadores de categoria. Eu faço algo assim manualmente.
Ser capaz de um grupo gerenciar um grupo significa que é mais fácil adicionar/remover donos sem que um administrador seja necessário. Como o Grupo de Donos de Grupo tem seus próprios donos principais que podem adicionar/remover membros regulares no grupo de donos.
Obrigado Dan — seu ponto sobre moderadores de categoria poderem possuir um grupo vinculado à sua categoria realmente ressoa. Parece que você está imaginando uma estrutura de administração mais flexível onde um grupo pode gerenciar outro grupo — e isso poderia ajudar muito a otimizar permissões e fluxos de trabalho.
Atualmente, o Discourse permite apenas que usuários individuais sejam proprietários de grupos. Mas em casos de uso do mundo real, especialmente comunidades estruturadas (como escolas, departamentos ou equipes), muitas vezes queremos dizer:
“Grupo A (por exemplo, coordenadores-de-mentores) pode gerenciar o Grupo B (por exemplo, mentores)”
…sem que os membros do A sejam adicionados ao B ou herdem sua identidade/distintivo
Isso permitiria:
Separação clara entre identidade (associação de grupo) e controle (propriedade de grupo)
Delegação de gerenciamento de membros (convidar/remover/aprovar) sem conceder acesso de administrador ou moderador em todo o site
A capacidade de vincular a moderação de uma categoria ao grupo que controla seu grupo de postagem
Parece que você está apontando para um modelo onde a propriedade do grupo aceita não apenas nomes de usuário, mas outros grupos. Essa ideia se alinha com alguns tópicos mais antigos:
