Groups ACL

Contribute Feature

AI-generated summary

In a discussion titled ‘Groups ACL’ under the Feature category, Crius expresses concern about Discourse’s lack of granular group-based access control, especially for backend/administrative tasks like managing users, approving accounts, or accessing settings — features common in CMS platforms. They wonder if this is a missing feature or if a plugin or roadmap item exists to support such flexibility. RGJ points to existing documentation on groups and category permissions, noting that while group-to-user relationships exist, actions are hardcoded and limited to basic permissions like ‘see, read, reply’ as detailed here. Crius clarifies they’re seeking fine-grained control over what groups can do — not just where they can act — and questions whether such a core feature could be implemented via plugin or is planned for Discourse itself. riking confirms that while some permissions (e.g., Category Moderators) are group-named via SiteSettings, dynamic permissions remain largely limited to category access, with no major overhaul currently planned.

1

I’ve seen some threads when searching on google about this topic but found no clear indication.

I’m planning a move from vBulletin3 → vBulletin5 and then exploring the possibility to move onto Discourse. The one major thing I was expecting from a modern solution like discourse is the possibility to manage/create groups and assign them granular access but it seems that it’s not the case.

Am I mistaken and simply missing the feature in the settings?
In case I am right, is there any official plan to eventually support this or a plugin that offer something of sorts?

Thank you

1 Like
2

I am not sure how granular you want things to be?

This is what is currently available in Discourse: Understanding groups and category permissions

2 Likes
3

Hey, thank you for the link, I’ll read through that.

What I meant is something alike most CMS, going on by listing all possible things would be a matter of listing possible actions performed by admins like CRUD operations on users, categories, topics, etc

It is one of the worst nightmare UI-wise but really a strong tool in term of customizability.

It would require to have dedicated tables like:
Users ← → Users_Groups ← → Groups ← → Actions_Groups ← → Actions

So that users can belong to one or more groups and groups can have one or more actions.
My concern is that it’s such a “core” feature that I don’t know if a plugin could do something like this.
Thus why I was asking if something is planned or existing for discourse itself.

Checking the link you suggest explain how to determine “where” the predefined roles can act but “what” they can do is pretty much set in stone and it’s pretty basic “see, read, reply”. Which is fine for “front office” stuff but there isn’t much in term of “back office” work.

Back office work is basically all the concern the maintenance of the plaform itself in term of administering and moderating. Granularity could be:

  • Can Manage users (all operations)
  • Can Approve users
  • Can Ban/Silence users
  • Can acces customization settings
  • Can access settings (even more detailed eventually)
  • …

Those are just example of course but I hope it’s clear what I mean.

1 Like
4

Users ← → Users_Groups ← → Groups exists,

But actions_groups is hardcoded and here’s how it’s hardcoded: Trust Level Permissions Reference

2 Likes
5

Yes I imagined that. That’s why I was asking if there is anything in the roadmap about reworking that feature to expand on it.

6

There has been some gradual migration of certain permissions into SiteSettings naming a single group. Category Moderators exist, naming a single group each. But for the most part, the only dynamic permission is category access.

2 Likes