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 « J'aime »
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 « J'aime »
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 « J'aime »
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 « J'aime »
Nous avons le même cas d’usage. Nous faisons appel à des prestataires externes (webdesigners) auxquels nous souhaitons accorder un accès à cette fonctionnalité. Un administrateur complet aurait accès à tout, y compris aux discussions de gestion privées, ce qui n’est pas souhaitable.
Il serait idéal de disposer d’un flux de travail permettant aux webdesigners de proposer ou de tester des modifications sans avoir un accès administrateur complet.
4 « J'aime »
Bonjour @Joaquin_Menchacha,
Merci pour votre message et pour ce rappel sur ce sujet.
Nous souhaitons également (prévoyons) d’affiner certains contrôles d’administration à l’avenir.
Par exemple, nous sommes intéressés par un plugin (un jour) qui sera configuré avec des variables dans le fichier de conteneur yml et qui restreindra certaines actions d’administration (comme le téléchargement de la sauvegarde complète du site) à certains utilisateurs uniquement (identifiants d’utilisateur).
Cette idée de plugin est « sur ma table de travail » et, dès que j’aurai l’occasion, je m’y pencherai plus en détail. Pour l’instant, je n’ai même pas encore fait le premier pas consistant à examiner le code et à évaluer la faisabilité de cette idée.
3 « J'aime »
Quelqu’un a-t-il trouvé une solution ici ?
J’ai le même cas d’usage où je souhaite accorder à certains de mes collaborateurs l’accès au thème et aux annonces internes.
La solution la plus simple est de faire confiance aux personnes et de leur attribuer le rôle d’administrateur ou de modérateur. Si vous ne leur faites pas confiance pour avoir un contrôle total, mais que vous souhaitez leur accorder un accès supplémentaire, vous aurez alors besoin d’un plugin.
1 « J'aime »
Ce n’est pas que je ne leur fais pas confiance. Mais en ce qui concerne notre modèle de menace, cela crée une surface d’attaque supplémentaire. Et si l’utilisateur spécifique était compromis en raison d’un manque de sécurité de son côté ? Il y a beaucoup de variables en jeu.
Nous explorerons donc l’option du plugin.
2 « J'aime »
D’accord, Discourse a besoin de contrôles supplémentaires pour la personnalisation. Comme d’autres l’ont mentionné, cela pourrait inclure la possibilité d’engager des prestataires externes pour utiliser des fonctions de niveau supérieur tout en protégeant les informations des membres.
La modération par groupe est correcte, mais il arrive que l’on souhaite certaines fonctions avancées d’un modérateur complet sans en avoir toutes les fonctionnalités.
Un plugin pourrait en effet s’avérer utile. Mais tout comme le plugin « Merge User » a été intégré au cœur du système, il faudrait également intégrer des fonctionnalités de modération/administration personnalisées plus puissantes afin de permettre plus de types de personnel.
1 « J'aime »
Je rejoins les autres contributeurs ici : le modèle de contrôle d’accès gagnerait à être amélioré avec une couche supplémentaire de granularité RBAC (contrôle d’accès basé sur les rôles) permettant de spécifier précisément ce que les staff et admin peuvent accéder (pour certaines fonctions, pas toutes).
Par exemple, un site pourrait souhaiter ajouter davantage d’administrateurs, mais préférer leur accorder un ensemble restreint de privilèges RBAC ; par exemple, autoriser ou non le téléchargement de la sauvegarde complète du site ou l’accès à certains fichiers de journaux d’actions du personnel. De plus, un site pourrait souhaiter s’assurer que certains membres du personnel n’ont pas les permissions RBAC pour consulter les actions du personnel effectuées par les administrateurs ou les développeurs, ou simplement certaines actions considérées comme plus « privées ».
Tous les experts en cybersécurité apprennent (et le savent par expérience directe) que la plus grande menace pour toute organisation est l’« employé mécontent » et non les pirates ou attaquants externes. Il ne fait aucun doute quant à ce risque fondamental en sécurité informatique, et c’est une connaissance bien établie pour les professionnels de la sécurité informatique formés ou expérimentés. Par conséquent, rejeter la menace intérieure en disant « faites simplement confiance à votre administrateur » ou « vous devez faire confiance à votre personnel » n’est pas une solution technique pour les professionnels de l’informatique. Même le personnel le plus digne de confiance, loyal depuis de nombreuses années, peut commencer à rencontrer des problèmes personnels susceptibles de le transformer en « employé mécontent ». De plus, ce sont les membres du personnel les plus privilégiés qui commettent le plus d’erreurs ; et nous savons tous que les erreurs bien intentionnées du personnel ou des administrateurs provoquent généralement plus d’arrêts de service que n’importe quel pirate, en général.
Il y a quelque temps, j’ai envisagé de modifier la classe Guardian de Discourse pour notre site, mais après un examen plus approfondi de cette classe, il ne m’a pas semblé évident qu’il existait une « solution rapide » me permettant d’écrire un minimum de code de patch (monkey patch) pour améliorer le RBAC de Discourse. Étant naturellement paresseux et préférant créer des solutions simples chaque fois que possible, j’ai mis cette idée de côté pour me consacrer à d’autres projets de « clients bien rémunérés ».
Par la suite, j’ai envisagé de descendre d’un niveau dans le code et de transférer certaines des fonctions staff et admin vers developer, mais cette approche nécessitait trop de patches (monkey patches), ce qui, à l’époque, ne me semblait pas être une bonne idée. Après tout, si nous pouvons accomplir quelque chose avec un seul patch plutôt qu’avec dix, il est évident qu’un seul patch est préférable.
Je n’ai pas encore eu le temps ni une « exigence urgente » d’approfondir cette partie du cœur de Discourse pour déterminer s’il existe une extension de plugin RBAC « facile » que je pourrais écrire via un plugin « relativement simple ».
Honnêtement, je pense que le problème est que je ne suis pas encore un super développeur Ruby et que, pour l’essentiel, je me considère davantage comme un « aspirant » codeur Ruby, LOL. Je suis convaincu qu’il existe, plus que probablement, une solution de plugin RBAC simple quelque part, mais personnellement, je ne l’ai pas encore trouvée. Peut-être qu’une personne Ruby beaucoup plus expérimentée pourra examiner rapidement le code et voir comment aborder ce problème.
Mon idée serait d’ajouter de nouveaux paramètres booléens au site qui limiteraient ou accorderaient des permissions RBAC spécifiques en fonction du rôle, puis d’intégrer ces booléens dans la partie appropriée du code via un patch (monkey patch) dans un plugin. Cependant, comme je l’ai mentionné, je préférerais patcher un seul fichier et non « plusieurs », afin que ce soit propre, simple et facile à maintenir.
Quand j’aurai le temps, j’étudierai plus en profondeur cette amélioration du RBAC, car elle est certainement intéressante.
1 « J'aime »
Bonjour @jrgong,
Ce n’est pas difficile à réaliser via un plugin, comme vous le savez probablement bien.
En gros, vous pourriez créer une liste de membres du personnel (par e-mail, nom d’utilisateur, etc.) en tant que paramètre global, de manière similaire à la façon dont Discourse définit les développeurs par adresse e-mail.
Ensuite, vous pourriez utiliser ce GlobalSettting dans certaines patches pour autoriser les deux cas d’usage qui vous intéressent.
Le premier de vos cas d’usage : personnaliser les thèmes en tant que membre du personnel, est relativement simple à implémenter via un monkey patch du cœur, je pense.
Pour le deuxième cas d’usage, avec peu de travail, vous pourriez forker ce plugin et redessiner la contrainte d’accès aux routes dans ce plugin (et tout autre changement nécessaire) :
Puisque la contrainte pour le plugin de publicité est intégrée au plugin, il est judicieux de modifier ce code pour permettre à votre personnel « autorisé » d’accéder aux parties de ce plugin que vous souhaitez autoriser, en fonction de votre propre RBAC.
Autrement dit, les deux exigences que vous souhaitez sont réalisables si vous êtes prêt à écrire le code ; ou bien, bien sûr, vous pouvez demander à l’un des développeurs de plugins Discourse experts de vous aider dans Marketplace.
2 « J'aime »
Merci @neounix, j’apprécie vraiment ton retour ! Je vais demander à un développeur de s’en charger.
edit : Y a-t-il vraiment aucune autre solution que de faire un fork du plugin ?
Et qu’en est-il de l’accès au plugin Babble Chat ? Cela nécessiterait-il aussi un fork ?
Nous parlons de logiciel.
Il existe toujours de nombreuses façons de faire les choses.
Je vous ai donné mes recommandations.
2 « J'aime »