Desculpe, é um post antigo, mas por que você não configura seu tema como um repositório no GitHub? Conceda permissão à sua equipe de design e UX para acessar e atualizar o tema no GitHub.
No Discourse, agora é possível configurar os temas para atualização automática após a reconstrução.
Seus administradores precisarão apenas reconstruir para incorporar quaisquer alterações feitas pela equipe de design e UX, e esta última não precisará de acesso administrativo em absoluto.
Apenas uma breve observação:
Ao lidar com questões de controle de acesso, em geral, essas verificações de RBAC devem ser realizadas no lado do servidor.
O código de RBAC em Javascript do lado do cliente pode ser manipulado pelo cliente.
Isso significa que, ao definir permissões básicas de RBAC para equipe, administradores e moderadores, isso deve ser feito (de modo geral) no Rails, e não no Javascript.
Aliás, é assim que o Discourse realiza o RBAC atualmente, usando o que o Discourse chama de “guardian”, uma classe Ruby chamada class Guardian, aqui:
Se um desenvolvedor for adicionar verificações de RBAC no código Javascript chamando a API do Discourse, lembre-se de que esse código pode ser comprometido, pois o código executado no navegador pode ser manipulado.
Minha recomendação é garantir que todo o código básico de RBAC seja executado no lado do servidor e não tente contornar isso no Javascript do lado do cliente.
Também existe o nível de confiança 4 e os moderadores de categoria, no Discourse 2.5 e versões posteriores.
Tenho um caso de uso semelhante: administro uma pequena comunidade sem fins lucrativos, onde um de nossos usuários é responsável pela manutenção dos temas e do design.
Não desejo conceder acesso a dados privados de usuários (como endereços de e-mail, etc.) a ninguém além de mim e do meu co-proprietário, mas tenho quatro moderadores.
Para que o designer possa trabalhar, precisei criar um site de cópia sem conteúdo, onde ele é administrador, e depois copio temas e componentes manualmente. No entanto, isso não é ideal, pois algumas alterações exigem conteúdo para serem validadas.
Por que não adicionar algum conteúdo ao site de staging/testes? Essa seria a recomendação típica.
Então, deixe o desenvolvedor trabalhar no site de staging e envie os temas para o GitHub. Mas você ainda precisará atualizá-los manualmente. Você pode tentar fazer a atualização usando a API e, de alguma forma, permitir que o desenvolvedor a acione.
Estou trabalhando em uma ferramenta que pode ajudar com isso.
Nós temos exatamente essa necessidade também, alguém por acaso resolveu isso?
Não sei se isso é útil nesta situação, mas se você precisar de algum conteúdo, existe a tarefa populate do rake:
Obrigado, infelizmente não é muito útil no momento.
Se você não confia no designer para ver seus dados, que solução você imaginaria?
Você poderia dar a eles apenas uma chave de API que os permitiria usar o discourse_cli para enviar o tema para lá e, em seguida, desativá-la quando terminassem, talvez?
Não há absolutamente nenhuma razão para um designer ter acesso a 100 mil usuários, lol. Além disso, seria contra as regras do GDPR. É possível fornecer uma chave de CLI apenas para atualizações de temas?
Peço desculpas! Acho que você está certo.
Agora, ao contrário de quando este tópico foi criado (que aparentemente era onde meu cérebro estava quando escrevi minha resposta), nós temos chaves de API granulares. Não deve ser muito difícil adicionar um novo escopo apenas para gerenciamento de temas.
Pode valer a pena criar um novo tópico em Feature pedindo um escopo de chave de API para desenvolvedor de temas. Isso parece uma ótima ideia.
Não, não é. Pode ser contra as regras desse site, mas essas regras podem e devem mudar.
Seria bom se @AV_C pudesse postar uma referência a este requisito. Embora eu possa apreciar fortemente por que um cliente gostaria de restringir o acesso à base de usuários e até mesmo a categorias privadas devido a uma variedade de razões. O administrador completo pode acessar os e-mails de inscrição dos membros e categorias privadas podem conter outro conteúdo sensível, dependendo do caso de uso do cliente.
Acho que @pfaffman tem uma boa ideia para garantir que esse tipo de lacuna possa ser coberto por meio de uma API de administrador restrita. Uma vez que o trabalho do designer seja concluído, a chave pode ser revogada até que seja necessária.
Isso também se encaixaria na ideia de Jay de não mostrar um usuário como administrador na página Sobre.