Sorry old post but why don’t you set up your theme as a repo in GitHub? Permission your design and UX team to have access to update the Theme in GitHub.
In Discourse you can now set Themes to auto update upon rebuild.
Your admins will now only need to rebuild to bring in any changes made by the Design and UX team and the latter will not need access to admin at all.
Just a short note:
When coding matters of access control, in general, these RBAC checks should be performed on the server side.
RBAC code in client-side Javascript can be manipulated by the client.
This means that when defining core RBAC permissions for staff, admins and moderators, this should be done (generally speaking) in Rails, not in Javascript.
OBTW, this is also how Discourse does RBAC now, using what Discourse calls “guardian”, a Ruby class called class Guardian, here:
If a developer is going to add RBAC checks in Javascript code by calling the Discourse API, keep in mind that this code can be compromised because code which runs in the browser can be manipulated.
My recommendation is to make sure all core RBAC code is performed on the server side and do not try to short cut this in client-side Javascript.
There is also trust level 4 and category moderators, in discourse 2.5 and beyond.
I have a similar use case, in that I run a small non-profit community where one of our users is maintaining the themes and design.
I do not wish to give anyone beside me and my co-owner access to private user data (e-mail addresses etc.), but I do have 4 moderators.
In order for the designer to work, I’ve had to create a copy site with no content where he is the admin, and I then copy themes and components manually. However it is not desirable since some changes requires content in order to proof.
Why not add some content to the staging / testing site? That’d be the typical recommendation.
So let the developer develop on the staging site, and push the themes to github. But you’ll still need to upgrade them yourself. You might contrive to do the upgrade with the API and somehow make the developer be able to trigger it.
I’m working of a tool that might be able to help with that.
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.