Hello!
I want to change user groups permissions, for example:
Admin Group - all permissions
Co Admin - can do anything but cannot open some sections on admin pane
How to do that? Thanks!
That’s not possible by default since admins have unrestricted access to all the sections of the forum. Depending on what kind of permissions you want to revoke, maybe demoting them to moderator can be helpful?
Moderator cannot create a categories and i want that
Mods can create categories if you enable the moderators_create_categories settings in your discourse admin.
4 curtidas
Where i find that? I looked through all the categories in the admin panel and did not see anything that I could assign to moderators.
*Is there something like moderators_create_themes?
Go to admin > Settings
Then search for the keyword moderators_create_categories
4 curtidas
Is your Discourse up to date?
What you are asking is, "Is there something like ‘moderators can crash the whole site by making a broken theme?’ ". I’m pretty sure that the answer is going to be “No.”
You could install a remote theme hosted in github that a moderator could change, but an admin would still need to pull in the changes.
You do not know who will tinker with the themes, how can you make that statement?
I asked this question because there are no groups with custom rules like it said above.
My point is that if you trust someone enough to change themes then you can make them an admin.
If you would like to allow non-admins to modify themes or otherwise change what a moderator can do you’ll need a custom plugin.
2 curtidas
Not in my current scenario. We have UX and Design teams and they are only responsible for that area, so only access to the themes would be necessary.
2 curtidas
Temos o mesmo caso de uso. Contamos com contratados externos (web designers) aos quais queremos conceder acesso a isso. Um administrador completo teria acesso a tudo, incluindo discussões de gerenciamento privadas, o que não é desejável.
Seria ideal ter um fluxo de trabalho que permita aos web designers enviar ou testar alterações sem necessidade de acesso total de administrador.
4 curtidas
Obrigado pelo seu post e lembrete sobre este tópico.
Também desejamos (planejamos) refinar alguns dos controles de administração no futuro.
Por exemplo, estamos interessados em um plugin (algum dia) que será configurado com variáveis no arquivo de container yml e restringirá certas ações de administrador (como baixar o backup completo do site) apenas a certos usuários (IDs de usuário).
Essa ideia de plugin está “na minha lista de tarefas” e, quando tiver a oportunidade, investigarei mais. Até agora, nem mesmo dei o primeiro passo de analisar o código e examinar a viabilidade dessa ideia.
3 curtidas
Alguém encontrou uma solução aqui?
Tenho o mesmo caso de uso, onde quero conceder acesso ao tema e acesso a anúncios internos para alguns membros da minha equipe.
A solução fácil é confiar nas pessoas e torná-las administradoras ou moderadoras. Se você não confia nelas com controle total, mas deseja que tenham acesso adicional, será necessário usar um plugin.
1 curtida
Não é que eu não confie neles. Mas, quando se trata do nosso modelo de ameaças, isso cria uma superfície de ataque adicional. E se o usuário específico for comprometido devido à falta de segurança do lado dele? Muitas variáveis em jogo.
Vamos explorar então a opção de plugins.
2 curtidas
Concordo: o Discourse precisa de controles extras para personalização. Como outros mencionaram, contratar contratados externos para usar funções de nível superior, ao mesmo tempo que protege as informações dos membros.
A moderação de grupos é razoável, mas às vezes você pode querer algumas funções mais avançadas de um moderador completo, mas não todas as funções.
Um plugin, de fato, pode ser útil. Mas, assim como o plugin “Merge User” foi incorporado ao núcleo, recursos personalizados mais robustos para moderadores/administradores também deveriam ser, permitindo mais tipos de equipe.
1 curtida
Concordo com os outros aqui de que o modelo de controle de acesso seria melhorado com uma camada extra de granularidade de RBAC (controle de acesso baseado em funções) que especifique o que staff e admin podem acessar (para certas funções, não todas).
Por exemplo, um site pode querer adicionar mais administradores; mas preferem conceder um conjunto menor de privilégios de RBAC para administradores; por exemplo, conceder ou não conceder a capacidade de fazer o download do backup completo do site ou acessar certos arquivos de log de ações da equipe. Além disso, um site pode querer garantir que alguns membros da equipe não tenham permissões de RBAC para visualizar as ações da equipe de administradores ou desenvolvedores, ou apenas certas ações que são consideradas mais “privadas”.
Todos os especialistas em cibersegurança são ensinados (e sabem pela experiência direta) que a maior ameaça a qualquer organização é o “insatisfeito interno” e não hackers ou atacantes externos. Não há dúvida sobre esse risco básico de segurança de TI, e é um conhecimento bem estabelecido para profissionais de segurança de TI treinados ou experientes. Portanto, descartar a ameaça interna com “apenas confie no seu administrador” ou “você deve confiar na sua equipe” não é uma solução técnica para profissionais de TI. Mesmo a equipe mais confiável, leal por muitos anos, pode começar a enfrentar problemas de vida que podem fazê-los se tornar um “membro da equipe insatisfeito”. Além disso, são os membros da equipe com mais privilégios que cometem mais erros; e todos sabemos que, em geral, erros bem-intencionados de equipe/administrador geralmente causam mais tempo de inatividade do que qualquer hacker.
Há algum tempo, considerei alterar a class Guardian do Discourse para o nosso site, mas após uma análise mais detalhada dessa classe, não foi óbvio para mim que havia uma “solução rápida” que me permitiria escrever uma quantidade mínima de código de monkey patch para melhorar o RBAC do Discourse. Sendo preguiçoso por natureza e preferindo criar soluções simples sempre que possível, deixei a ideia de lado e segui para outros projetos de “clientes bem remunerados”.
Subsequentemente, considerei descer um nível no código e transferir algumas das funções de staff e admin para developer, mas essa abordagem exigia muitos monkey patches, o que eu achei que não era uma boa ideia na época. Afinal, se podemos realizar algo com um monkey patch em vez de dez, obviamente um patch é melhor.
Ainda não tive tempo ou uma “necessidade urgente” para investigar mais profundamente essa parte do núcleo do Discourse e determinar se há uma melhoria de plugin de RBAC “fácil” que eu possa escrever por meio de um plugin “relativamente simples”.
Honestamente, acho que o problema é que ainda não sou um super rubyista e, na maior parte, me considero mais um “aspirante” a programador Ruby, LOL. Tenho certeza de que, muito provavelmente, existe uma solução simples de plugin de RBAC por aí, mas pessoalmente, ainda não a encontrei e talvez uma pessoa Ruby muito mais experiente possa olhar rapidamente para o código e ver como abordar isso.
Minha ideia seria ter algumas novas configurações de site booleanas que limitariam ou concederiam permissões específicas de RBAC com base na função e, em seguida, adicionar esses booleanos à parte apropriada do código por meio de um monkey patch no plugin. No entanto, como mencionei, prefiro corrigir um arquivo, não “muitos”, para que seja limpo e simples, fácil de manter.
Quando tiver tempo, investigarei mais essa melhoria de RBAC, pois é interessante, com certeza.
1 curtida
Olá @jrgong
Isso não é difícil de fazer por meio de um plugin, como você provavelmente sabe bem.
Basicamente, você poderia criar uma lista de membros da equipe (por e-mail, nome de usuário, etc.) como uma configuração global, de forma semelhante à maneira como o Discourse define desenvolvedores por endereço de e-mail.
Em seguida, você poderia usar essa GlobalSetting em alguns patches para permitir os dois casos de uso que você tem interesse.
O primeiro dos seus casos de uso: personalizar temas como membro da equipe, é relativamente direto de aplicar um monkey patch no núcleo, eu acho.
Quanto ao segundo caso de uso seu, com pouco trabalho, você poderia fazer um fork desse plugin e redesenhar a restrição de acesso à rota neste plugin (e quaisquer outras alterações necessárias):
Como a restrição para o plugin de anúncios está integrada ao plugin, é uma boa ideia alterar realmente esse código para permitir que sua equipe “permitida” acesse as partes desse plugin que você deseja permitir, com base no seu próprio RBAC.
Em outras palavras, ambos os requisitos que você deseja são viáveis, se você estiver disposto a escrever o código; ou, claro, você pode pedir ajuda a um dos profissionais habilidosos no desenvolvimento de plugins do Discourse no canal Marketplace.
2 curtidas
Obrigado @neounix! Agradeço muito a contribuição! Vou pedir a um desenvolvedor para resolver isso.
edit: Não há outra maneira além de fazer um fork do plugin?
E quanto ao acesso ao plugin de chat Babble? Isso também exigiria um fork?
Estamos falando de software.
Sempre há muitas maneiras de fazer as coisas.
Forneci minhas recomendações.
2 curtidas