Skip to main content
Home  ›  Blog

DNN 10 with new CMS Editor Permissions

Dnn has long been burdened by content editors having full admin permissions. Now thanks to the detailed permissions we are introducing, we'll also create special Content Managers roles πŸ•ΊπŸΎ!

What Problem are we Solving?

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.

Doesn't Every CMS Have Content-Managers Groups?

Nope, DNN does not - at least not as of now. What's interesting is that the official DNN Documentations keep mentioning that this kind of role already exists. This was either documented and never implemented, or only available in Evoq, even though the docs imply that it's also available in DNN. 

Current Plans to Introduce New Groups

Accordingingly it seems that we should extend the default roles to:

  1. Administrators (βœ… existing)
  2. Registered Users (βœ… existing)
  3. Content Editors (πŸ†• documented but so far not in DNN Community)
  4. Content Managers (πŸ†• documented but not in DNN Community, πŸ€” unclear how this would be different from Content Editors, so maybe not) - apparently this role is an Editor + Publish capability.
  5. Community Managers (πŸ›‘ 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 determine what they would do. 

Updated 2024-05-31: According to feedback from Evoq users, the difference between Content Managers and Content Editors seems to be, that Content Editors can make changes, but not publish them. So our current plan is to introduce these two system roles with the following behavior:

  1. Content Editors - who can edit every content, add/change/move pages etc.
  2. Content Managers - same as the above, but with additional publish rights (currently not implemented yet, will have to look into this some more)

For now, we don't see a reason to implement Community Managers, but this may change as we get more feedback from the community. 

Planned Setup

As of now, we believe the setup should be as follows:

  1. These new roles should be pre-installed by default
  2. These new roles 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. On upgrade, the roles should be somehow added automatically (TBD)
    🀚🏾 WARNING: Some sites may already have roles with exactly this name. We will have to determine how to handle such situations, as the name is the identifier of the role.

The permissions granted to all Content Managers should be:

  • Page
    • Create
    • Edit settings (eg. rename, hide, ...)
    • Change layout / theme
    • Move (in navigation)
    • Delete
    • Manage Permissions
    • etc. - basically everything
    • ...ideally this would apply only to standard pages, not system pages. This is almost obsolete today, as Dnn has almost all admin-UIs in JS / React.
  • Module
    • Add modules
    • Edit module settings incl. title, container
    • Add modules to other pages
    • Delete modules
    • Edit module contents
  • Files: every possible action
  • Recycle Bin: every possible action

The permissions granted to all Content Editors should be:

  • Page: Same as Content Managers
  • Module: Same as Content Managers
  • In terms of managing permissions, we may consider restricting content editors, but we're not sure yet, since it's typical for editors to specify the pages audience etc. 
  • Recycle bin: this should probably be restricted so the content-editor cannot clean it, but possibly only restore things.

So for now - and probably for the release of Dnn 10.00 these roles will probably behave identically. But we are planning to review publishing processes as well, in which case their purpose will become different in Dnn 10.1 or 10.2. 

What must be Done?

  1. Wait for: First we must get detailed/advanced permissions done
    πŸ“ˆ this is 90% complete as of May 2024
  2. Permissions Provider: Next we must create or update the permissions provider to
    πŸ“ˆ this is 50% complete as of May 2024
    1. know about these new roles
    2. automatically give permissions to these roles
    3. not allow removing any of these permissions, since this would confuse everybody
  3. UI Restrictions: Then we must get the admin-UIs in sync with the changes
    πŸ“ˆ this has not been started
    1. Prevent delete / rename of these new system roles (similar to Administrators / Registered Users)
    2. Prevent changing permissions of these roles on pages / modules (similar to Admins)
  4. Persona Bar Changes: the persona bar should hide most admin features for these groups, and only keep a few button such as
    πŸ“ˆ this has not been started
    1. Manage pages / menu
    2. Manage files aka "site assets" - it should be reviewed if these should go into the same menu to keep things simple
  5. Recycle Bin changes: 
    πŸ“ˆ this has not been started
    1. Ideally the Content Manager can do everything
    2. ...but the Content Editor can only restore things, but never flush the bin.

Upgrade Considerations

Because systems will be upgrading there are a few gotchas to keep in mind:

  1. If a system already has roles called Content Managers or Content Editors which were meant for something other, they should consider renaming their own roles first, since afterwards the permissions of these system-roles will be hard-wired. 
  2. As of now we plan to provide this functionality as the default, but using a new permissions provider, so that anybody who doesn't want these features can fall back to just using the old CorePermissions.

Thanks to Tonci!

We are really excited about this!

Big kudos to Tonci, who has been burning the midnight oil for all of us!

Love from Switzerland,
iJungleboy

 


Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see github), an open source module for creating attractive content and DNN Apps.

Read more posts by Daniel Mettler