Acho que adicionar proprietários de grupos poderia ser feito em grande parte como está agora, exceto pela adição da capacidade de @grupo adicionar como proprietário.
O principal benefício é que o grupo de proprietários terá seu próprio proprietário, muito provavelmente apenas um ou dois membros.
Para manter as coisas organizadas, uma verificação de sanidade pode ser que a propriedade seja apenas em 1 nível de profundidade.
Ou seja, o Grupo A é proprietário do Grupo B e é considerado membro de ambos os grupos.
Agora, se adicionarmos o Grupo C e ele for propriedade do Grupo B. O Grupo B é proprietário do Grupo C. Enquanto o Grupo A é proprietário do Grupo B. O Grupo A é considerado apenas um membro do Grupo C, mas não tem privilégios de propriedade.
Realmente aprecio o esclarecimento, Dan — limitar a propriedade de grupo para grupo a um nível de profundidade faz muito sentido para a manutenibilidade e para evitar o acúmulo de privilégios.
Gosto da ideia de que:
Grupo A é proprietário do Grupo B → membros do A obtêm direitos de proprietário no B
Grupo B é proprietário do Grupo C → membros do B obtêm direitos de proprietário no C
Mas o Grupo Anão é proprietário do C — apenas transitivamente um membro (não gerente)
Isso ajuda a evitar aninhamento infinito, ao mesmo tempo que suporta estruturas de delegação úteis.
Também concordo que limitar a profundidade de propriedade por meio de uma configuração group_ownership_nesting_level (como aninhamento de subcategorias) oferece flexibilidade aos sites — talvez o padrão seja 1, mas permitindo a opção de controle mais profundo, se necessário.
Algumas perguntas esclarecedoras que eu tinha:
Em seu modelo, o grupo proprietário deve aparecer como um membro do grupo possuído na interface do diretório de grupos? Ou a associação é puramente baseada em permissão?
Se um grupo tiver vários proprietários (alguns usuários, alguns grupos), como você vê a resolução de conflitos ou redundâncias na interface?
A propriedade afetaria as permissões de categoria (por exemplo, o grupo proprietário poderia gerenciar a categoria vinculada ao grupo possuído)?
Isso abriria muita flexibilidade em fóruns baseados em educação, organização ou projetos — obrigado por manter a ideia em movimento!
Para isso, o Grupo Proprietário do Grupo precisaria ser visto como membros com talvez o rótulo de proprietário ou algo assim.. Na minha opinião, o grupo de proprietários precisa herdar a associação básica do Grupo para fins de permissões de Categoria e, se Público, para mostrar todos os membros. Talvez parecido com como os Moderadores de Categoria podem ser listados na página Sobre do Site como Moderadores. Talvez seja tão simples quanto listar o Grupo Proprietário como Proprietário/gerenciado por. Então um membro pode simplesmente clicar no grupo proprietário para ver os Proprietários de tal Grupo?
Na minha opinião, se você estiver usando um Grupo como proprietários. Então talvez sejam proprietários membros dentro do Grupo ou gerenciados por um grupo. Não uma mistura de ambos.
Você quer dizer como Moderadores de Categoria? Se sim, uma alteração foi feita para permitir que mais de um grupo gerencie uma categoria. Embora, se usar o exemplo da pergunta anterior. Poderia simplesmente ir com o Grupo de Proprietários herda as permissões do grupo gerenciado. Então Permissões de Categoria e neste caso também seriam Moderadores de Categoria. Nos Moderadores de Categoria, daria mais níveis de gerenciamento como com outros exemplos. Um conjunto principal de proprietários que podem remover proprietários inferiores, se necessário, sem exigir que a equipe completa intervenha. Ou seja, 2 proprietários em conflito. O proprietário principal do grupo de gerentes pode rebaixar, se necessário.
Este é um ótimo exercício de pensamento para aprimorar a ideia. Então, muita discussão é ótima para analisar a ideia.
Heliosurge sobre visibilidade de propriedade e permissões de categoria
Isso faz sentido — gosto da ideia do grupo proprietário aparecer no diretório de grupos com um rótulo de “Proprietário” ou “Gerenciado por”, semelhante a como os moderadores de categoria são exibidos.
Acho que a distinção entre:
Membros plenos (que recebem distintivos, menções, flair de grupo)
E proprietários via outro grupo (que herdam permissões, mas não identidade)
…seria útil manter claro na interface do usuário.
Layout de exemplo
Grupo @mentors
Membros: Alice, Bob, Charlie
Grupo Proprietário: @mentor-coordinators
Onde clicar no grupo proprietário leva você à sua lista de membros.
E concordo — para fins de permissão de categoria, é elegante tratar os grupos proprietários como “membros” dos grupos que eles possuem (para evitar a necessidade de duplicar permissões manualmente).
Perguntas de acompanhamento
Você veria a associação do grupo proprietário herdando apenas para verificações de permissão, ou também aparecendo em coisas como menções de grupo e flair, se o grupo possuído for público?
Seria possível para um grupo possuir vários outros grupos, ou deveria haver uma regra de propriedade 1:1 como uma restrição de segurança?
Heliosurge sobre o modelo de propriedade exclusiva
Ah, entendi — essa é uma simplificação útil.
Então você está sugerindo que a propriedade deve ser exclusiva:
Ou um grupo é possuído por usuários individuais
Ou é possuído por um grupo (que contém as pessoas com a propriedade)
Mas você não permite ambos ao mesmo tempo
Isso definitivamente mantém o modelo limpo e evita conflitos na interface do usuário.
Solução alternativa híbrida
Se alguém quisesse um híbrido, poderia sempre criar um grupo de propriedade (por exemplo, @mentors-owners), incluir proprietários individuais e representantes de subgrupos, e atribuir esse como o único grupo proprietário. Mantém as coisas organizadas sem misturar modelos de propriedade diretamente.
Perguntas de implementação
Essa exclusividade deve ser aplicada no nível do banco de dados (por exemplo, um grupo tem um group_owner_idou uma lista de user_owners, mas não ambos)?
Ou mais uma convenção de nível de interface do usuário com um aviso?
Um grupo deve ter permissão para ser possuído por mais de um grupo (assumindo nenhuma aninhamento)?
Heliosurge sobre herança de moderação de categoria e hierarquia de proprietários
Essa é uma direção útil, obrigado!
Sobre a herança de permissões de categoria
Sim — eu estava pensando em uma situação em que:
O Grupo B tem acesso de postagem/resposta/criação a uma categoria (por exemplo, #mentorship)
O Grupo A possui o Grupo B
Assim, o Grupo A também herda o acesso a #mentorship — sem precisar de permissões explícitas em nível de categoria
Isso manteria o gerenciamento de acesso mais simples se a estrutura de propriedade já expressasse o limite de confiança.
Sobre moderação de categoria
Bom saber que o Discourse agora permite que vários grupos moderem uma categoria.
Você imaginaria que o grupo proprietário do Grupo B também ganharia automaticamente o status de moderador de categoria para as categorias que o Grupo B modera?
Isso poderia ajudar a implementar um modelo de controle em camadas — onde os grupos proprietários podem atuar como “moderadores principais” ou “supervisores de grupo”, capazes de:
Moderar no mesmo espaço
Rebaixar proprietários de grupo ou subgerentes problemáticos
Perguntas de acompanhamento
As permissões herdadas se aplicariam apenas ao acesso/moderação de categoria? Ou poderiam também se estender a outros recursos vinculados a grupos (por exemplo, mensagens, eventos)?
Em seu modelo em camadas, o grupo “superior” deve ser sempre plano — ou ele próprio pode ter proprietários?
Isso parece estar construindo um modelo de delegação realmente flexível — útil para escolas, organizações e comunidades online estruturadas.