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.
Nous avons exactement le même besoin, quelqu’un a-t-il trouvé une solution par hasard ?
Je ne sais pas si cela est utile dans cette situation, mais si vous avez juste besoin de contenu, il y a la tâche rake populate :
Merci, malheureusement, ce n’est pas très utile pour le moment.
Si vous n’avez pas confiance dans le designer pour voir vos données, quelle solution imagineriez-vous ?
Pourriez-vous lui donner une clé API qui lui permettrait d’utiliser le discourse_cli pour y pousser le thème, puis la désactiver une fois qu’il aurait terminé, peut-être ?
Il n’y a absolument aucune raison pour qu’un designer ait accès à 100 000 utilisateurs lol. De plus, ce serait contraire aux règles du RGPD. Est-il possible de donner une clé CLI uniquement pour les mises à jour de thème ?
Veuillez m’excuser ! Je pense que vous avez raison.
Maintenant, contrairement à la création de ce sujet (qui était apparemment dans ma tête quand j’ai écrit ma réponse), nous avons des clés API granulaires. Il ne devrait pas être trop difficile d’ajouter une nouvelle portée juste pour la gestion des thèmes.
Cela pourrait valoir la peine de créer un nouveau sujet dans Feature pour demander une portée de clé API pour les développeurs de thèmes. Cela semble être une excellente idée.
Non, ce n’est pas le cas. Cela peut être contre les règles de ce site, mais celles-ci peuvent et devraient changer.
Il serait bon que @AV_C puisse poster une référence à cette exigence. Bien que je puisse fortement apprécier pourquoi un client voudrait restreindre l’accès à la base d’utilisateurs et même aux catégories privées pour diverses raisons. L’administrateur complet peut accéder aux e-mails d’inscription des membres et les catégories privées peuvent contenir d’autres contenus sensibles en fonction du cas d’utilisation du client.
Je pense que @pfaffman a une bonne idée pour garantir que ce type de lacune puisse être couvert par une API d’administration restreinte. Une fois le travail de conception terminé, la clé peut être révoquée jusqu’à ce qu’elle soit nécessaire.
Cela correspondrait également à l’idée de Jay de ne pas afficher un utilisateur comme administrateur sur la page À propos.