[Enhancement]: Proposal for Edit-only System User Roles for Content Managers

[iJungleboy]

Is there an existing issue for this?

• I have searched the existing issues

Description of problem

A pain in DNN has been that any user who can edit all pages must also be an Administrator.
Without the admin-permissions, the user must be assigned to every single page he can touch,
and new pages could accidentally be created without assigning these permissions.

What we need is a standardized "Content Managers" group, which would contain
all users who should just create pages, add modules and more,
but should not muck with the site settings or - heaven forbid - create new users who then might be admins.

What's interesting is that the official DNN Documentations
keep mentioning that this kind of role already exists
https://www.dnnsoftware.com/docs/content-managers/persona-bar-by-role.html

This was either documented and never implemented, or only available in Evoq, even though the docs imply that it's also available in DNN Platform (I assume that means normal DNN).

Description of solution

See also our blog post describing this and ongoing progress: https://2sxc.org/en/blog/post/dnn-10-with-new-cms-editor-permissions

Accordioning, it seems that we should extend the default roles to:

1. Administrators (existing)
2. Registered Users (existing)
3. Content Editors (new, but already documented, but unclear how this would be different from content managers, so maybe we should skip this)
4. Content Managers (new but documented
5. Community Managers (new but documented, unclear if this would make sense in Dnn)

So my proposal is that we implement the roles "Content Managers" in DNN.
If we should also add "Content Editors" and "Community Managers" in DNN should be evaluated, to better determined what they would do, so I see that as a future possibility.

I believe the setup should be as follows:

1. The role should be pre-installed by default
2. The role should be system-controlled like Administrators, giving consistent permission all the time, without allowing any custom modifications. Any other need should be handled using custom roles, not system roles.
3. The permissions granted should be:

• Page: Create, edit settings (eg. rename, hide, ...), move (in nav), delete; ideally only on standard pages, not system pages
• Module: Create, edit, move, delete; probably also settings like title etc.

We should check if there are specific permissions on page or module which should be restricted.
Examples could be:

1. maybe not allow configuring permissions?
2. maybe not allow delete? probably doesn't make sense though...

Description of alternatives considered

ATM you could get a similar effect my manually setting permissions on every page, but this is very error prone and gets forgotten when adding new pages or translating existing ones.

Anything else?

No response

Do you be plan to contribute code for this enhancement?

• Yes

Would you be interested in sponsoring this enhancement?

• Yes

Code of Conduct

• I agree to follow this project's Code of Conduct

[iJungleboy]

I believe this is related to #6042

[tvatavuk]

AdvancedPermissionProvider implemented backend support for advanced roles, specifically Content Editors and Content Managers. The feature inherited from the existing PermissionProvider, ensuring compatibility and leveraging current functionalities to offer a comprehensive solution for managing detailed permissions.