Skip to main content
Home  ›  Blog

Hidden DNN Gem: Detailed Permissions

Dnn has many hidden capabilities. We're about to make detailed permissions visible and accessible to everybody.

Background: Hidden DNN Gems

DNN has many hidden capabilities. They are hidden because DNN was built to do lots of things. This flexibility requires decisions such as "what is the default", and with many of these hidden gems, the default often seems to be "what was possible since DNN 4".

This allowed third parties to create alternate implementations, but as we discovered working with the source-code of DNN, many of these flexible features are so unknown, that nobody is actually implementing them.

Detailed Dnn Permissions

Tonci and I have been spending some time with user permissions, since we believe that this is lacking. 

What's exciting is that DNN actually has internal mechanisms such as "CanUserAddContent" which is tied to the permission "Edit" in all cases - as if someone forgot to use correct verbs for each use case.


It's clear that we could easily add more verbs, such as "CanAddContent" to
give the user more detailed permissions, with minimal changes to the code.

Interestingly there are already many such verbs mentioned in the code, so that "ContentModulePermissionKey" is already in the code using the verb "Content", just not where the official constant is stored.

Personally I would prefer "CanAddContent" to "CONTENT", since it's more explicit. But it's probably best to use the same terminology as is in the code, just in case someone actually did implement this in the way the code handles it. 

Implementing Detailed Permissions

So the API already implements detailed permissions to 99%, it's really just missing three things:

  1. the proper constants in the code
  2. the UI to make configure the permissions
  3. some additional code to ensure that both the correct verb (CONTENT) and the master-verb (EDIT) are both respected, ideally also ensuring that deny-permissions will be handled correctly. 

Implementing Part 1: Constants

This of course is a no-brainer - just change the code. Since there is an imaginable edge case where people would somehow want to go back to using the old one, it's probably better done in a new DetailedPermissionProvider or AdvancedPermissionProvider

Implementing Part 2: UI

It turns out that the UI will automatically show these permissions if the verbs are listed in the DB. So adding this to the DB:

Will get the UI to automatically show the options!! 💃🏾

Implementing Part 3: Code to Respect the Verbs

As we already noticed in the code, it's already there. All we must do is extend existing code from this...

...to handle both verbs  - eg both EDIT and CONTENT, and of course properly ensure DENY if a toggle is set to that.

TL;DR

Once we've gone through everything it's a no brainer. We're still polishing the details, like figuring out the final naming etc, but the PR is already in the queue and we look forward to including this in DNN 10 within a few weeks!

Love from Croatia and Switzerland,
Tonci & iJungleboy

PS: Big shoutout to Tonci! He's been burning the midnight oil for this!


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