How to define custom permissions for staff, admins, moderators

dgateles · July 10, 2019, 10:29am

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!

itsbhanusharma · July 10, 2019, 10:40am

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?

dgateles · July 10, 2019, 10:43am

Moderator cannot create a categories and i want that

itsbhanusharma · July 10, 2019, 10:45am

Mods can create categories if you enable the moderators_create_categories settings in your discourse admin.

dgateles · July 10, 2019, 10:47am

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?

itsbhanusharma · July 10, 2019, 10:49am

Go to admin > Settings
Then search for the keyword moderators_create_categories

pfaffman · July 10, 2019, 5:47pm

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.

dgateles · July 10, 2019, 5:51pm

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.

pfaffman · July 10, 2019, 5:53pm

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.

dgateles · July 10, 2019, 5:56pm

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.

Joaquin_Menchacha · June 9, 2020, 12:55am

We have this same use case as well. We have outside contractors (web designers) that we want to grant access to this. An full admin would have access to everything, including private management discussions, which is something not desirable.

It would be nice to have a workflow that allows web designers submit or try changes without full admin access.

neounix · June 9, 2020, 3:21am

Hi @Joaquin_Menchacha

Thank you for your post and reminder on this topic.

We also wish (plan) to refine some of the admin controls in the future.

For example, we are interested in a plugin (someday) which will be configured with variables in the yml container file and will restrict certain admin actions (like downloading the full backup of the site) to only certain users (userids).

This plugin idea is “on my plate” and when I get a chance, I’ll look into it more. So far, I have not even taken the first step of looking at the code and examining the feasibility of this idea.

jrgong · December 10, 2020, 2:46pm

Has any one found a solution here?

I have same use case where I want to grant theme access and house ads access to some of my staff members.

pfaffman · December 10, 2020, 2:57pm

The easy solution is to trust people and make them an admin or moderator. It you don’t trust them with full control, but want them to have additional access then you’ll need a plugin.

jrgong · December 10, 2020, 3:00pm

It’s not that I don’t trust them. But when it comes to our threat model, it creates an additional attack surface. What if the specific user gets compromised due to lack of security on his side? A lot of variables at play.

We will explore plugin option then.

Heliosurge · December 11, 2020, 7:34pm

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.

neounix · December 12, 2020, 2:46am

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.

github.com

discourse/discourse/blob/0ec62358d9f6cc6e9c82346a0ebc40161bea61d8/lib/guardian.rb#L88


      
          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.

neounix · December 12, 2020, 5:55am

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):

github.com

discourse/discourse-adplugin/blob/main/plugin.rb#L73


      
            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

jrgong · December 12, 2020, 11:15am

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?

neounix · December 12, 2020, 11:34am

We are taking about software.

There are always many ways to do things.

I provided you my recommendations.

Topic		Replies	Views
Delegating additional trust to moderators or other groups Feature	13	1247	February 21, 2018
Admin Restrictions? Feature	22	6342	October 17, 2024
Category Moderators Enhancer Plugin category-moderators	31	2308	November 15, 2024
Category-Specific Moderators, phase 1 RFC Feature rfc	72	18654	July 10, 2021
Theme-Component v Plugin: What's the difference Dev	22	5366	June 9, 2020

How to define custom permissions for staff, admins, moderators

Related topics