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!

Agreed Discourse needs extra controls for customization. Like what others have mentioned with hiring outside contractors to use higher level functions while still protecting members information. Group moderation is decent but sometimes you might want some higher functions of a full Mod but not all of the functions. A plugin indeed might be helpful. But like Merge User Plugin was merged into core; so should stronger moderator/admin customized features to allow more staff types.

[image] Heliosurge: A plugin indeed might be helpful. I agree with others here that the access control model would be improved with an extra layer of RBAC (roles-based access control) granularity that specifies what staff and admin can access (for certain functions, not all). For example, a site might want to add more admins; but they prefer to grant smaller set of admin RBAC privileges; for example, grant or not grant the ability to download the entire site backup or to access certain staff action log files. In addition, a site might want to insure that some staff do not have the RBAC permissions to view staff actions of admins or developers, or just certain actions which are considered more “private”. All cybersecurity experts are taught (and know by direct experience) that the largest threat to any organization is the “disgruntled insider” and not outside hackers or attackers. There is no doubt about this basic IT security risk, and it is well established knowledge for trained or seasoned hands-on IT security professionals. Therefore, dismissing the insider threat with “just trust your admin” or “you must trust your staff” is not a technical solution, for IT professionals. Even the most trustworthy staff, loyal for many years, can start experiencing life problems which can cause them to shift to be a “disgruntled staff member”. In addition, it is the most privileged staff which make the most errors; and we all know that well-intended staff / admin mistakes generally cause more downtime than any hacker, generally speaking. A while back, I considered altering Discourse class Guardian for our site but after further examination of that class it was not obvious to me there was a “quick fix” which would allow me to write a minimal amount of monkey patch code to enhance the RBAC for Discourse. Being lazy by nature and preferring to create simple solutions whenever possible, I put the idea on the back burner and moved on to other “well paid client” projects. lib/guardian.rb 0ec62358d end def authenticated? @user.present? end def is_admin? @user.admin? end def is_staff? @user.staff? end def is_moderator? @user.moderator? end def is_category_group_moderator?(category) return false unless category return false unless authenticated? Subsequently, I considered going a level down in the code and transferring some of the staff and admin functions to developer, but this approach required too many monkey patches, which I thought was not a good idea at the time. After, all if we can accomplish something with one monkey patch versus ten, obviously one patch is better. I have not yet had the time or a “burning requirement” to look deeper into this part of Discourse core to determine if there is an “easy” RBAC plugin enhancement I can write via a “relatively simple” plugin. Honestly, I think the problem is that I am not yet a super rubyist and for the most part, consider myself more of a “wannabe” ruby coder, LOL. I am confident there is, more-than-likely, a simple RBAC plugin solution out there, but personally, I have not found it yet and perhaps a much more experienced Ruby person can quickly look at the code and see how to approach this. My idea would be to have some new boolean site settings which would either limit or grant specific RBAC permissions based on role, and to then add those booleans to the appropriate part of the code via a monkey patch in plugin. However, I as mentioned, I would prefer to patch one file, not “many” so it is clean and simple, easy to maintain. When I have time, I will look into this RBAC enhancement more deeper since it is interesting, for sure.

[image] jrgong: have same use case where I want to grant theme access and house ads access to some of my staff members. Hi @jrgong This is not difficult to do via a plugin, as you probably know well. Basically, you could create a list of staff (by email, username, etc) as a global setting, similar to how Discourse defines developers by email address. Then, you could use that GlobalSettting in some patches to permit the two use cases are you are interested in. The first of your use cases: customize themes as staff, is relatively straight forward to core monkey patch, I think. The second use case of yours, with not much work, you could fork this plugin and redesign the route access constraint in this plugin (and any other required changes): plugin.rb main scope.show_carbon_ads? end add_to_serializer :current_user, :show_amazon_ads do scope.show_amazon_ads? end add_to_serializer :current_user, :show_adbutler_ads do scope.show_adbutler_ads? end add_to_serializer :current_user, :show_to_groups do scope.show_to_groups? end class AdPlugin::Engine < ::Rails::Engine engine_name "adplugin" isolate_namespace AdPlugin end AdPlugin::Engine.routes.draw do Because the constraint for the ads plugin is built into the plugin, it’s a good idea to actually change that code to permit your “permitted” staff to access the parts of that plugin you wish to permit, based on your own RBAC. In other words, both of the requirements you want are both doable, if you are willing to write the code; or of course you can ask one of the skillful Discourse plugin dev pros to help you in #marketplace

Thx @neounix I really appreciate the input! I will get a dev to get it done edit: Is there no other way but to fork the plugin? And how about access to babble chat plugin? That would also require a fork?

[image] jrgong: edit: Is there no other way but to fork the plugin? We are taking about software. There are always many ways to do things. I provided you my recommendations. :slight_smile:

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: lib/guardian.rb main # frozen_string_literal: true require "guardian/bookmark_guardian" require "guardian/category_guardian" require "guardian/ensure_magic" require "guardian/group_guardian" require "guardian/invite_guardian" require "guardian/flag_guardian" require "guardian/permalink_guardian" require "guardian/post_guardian" require "guardian/post_revision_guardian" require "guardian/sidebar_guardian" require "guardian/staff_action_log_guardian" require "guardian/tag_guardian" require "guardian/topic_guardian" require "guardian/upload_guardian" require "guardian/user_guardian" require "guardian/localization_guardian" # The guardian is responsible for confirming access to various site resources and operations This file has been truncated. show original 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.

[image] dgateles: We have UX and Design teams and they are only responsible for that area, so only access to the themes would be necessary. 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.

How to define custom permissions for staff, admins, moderators

Product Support

Jagster (Jakke Flemming) March 9, 2023, 5:58pm 33

No, it is not. It can be against rules of that site, but those can and should change.

Topic		Replies	Views
Admin Restrictions? Feature	22	6921	October 17, 2024
Grant customization rights to a non-admin Product Support	3	542	March 31, 2023
Restrict themes to certain groups? Product Support	6	1337	May 14, 2019
Allow moderators to create groups Feature	47	9076	April 11, 2023
How i can manage roles for moderators and administrators? Product Support	4	1388	June 12, 2022

How to define custom permissions for staff, admins, moderators

Related topics