New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Custom Module Permissions. Enhance your modules!

There's a "old" feature in DNN that allows module developers to create their own custom permissions for the modules they are creating. This will allow you to create a module and specify more granular permissions than the default VIEW / EDIT options DotNetNuke provides by default.

Yet a very powerfull feature I've seen this option not being much used. Actually very few module use that.
Why? I think the reason is because of a lack of documentation and examples from DNN core modules itself (an exceptional exception is the UDT module, from which I based some of this code). So I thought it would be good idea to provide some explanation on this and a piece of sample code for everybody to use.

What do we want
The overall goal of this exercise is to create some custom permissions for a module so it can have other options than the VIEW / EDIT default permissions. For example, decide which roles will be able to edit a specific item in the module.
The new permissions for the module will appear *automatically* on the permission grid in the module settings page without any extra step on your (the developer) part.

DotNetNuke provides two tables that support this feature. First there is the Permission table where all permissions are defined

and then we have the ModulePermission table where permission for each module are stored.

Note that this table contains not just module related permissions but all permission types (including folder and tabs). If at any given time DNN supports more granular permissions for these objects you will see them defined here.

On the Modules side note that the default permissions are defined with a code of "SYSTEM_MODULE_DEFINITION".
So the first thing to do when creating custom permissions is decide a unique code for your module. I suggest you use something similar to "MODULE_YOURMODULENAME".
ModuleDefId is a reference to the module that "owns" the permissions and PermissionKey, PermissionName define every permission you want to add.

A small problem with the current solution is that DNN does not provide any automated way to install new permission definitions when a module is installed. I'm sure we will solve this in a future version.

So we'll have to create some code to handle this, and the best way of doing it is by implementing the core IUpgrade interface. This interface defines a method that will be called everytime a new version of the module is installed, even the first version. So just add this piece of code to your controller class to handle the setup of module permissions:

  162         public string UpgradeModule(string Version)

  163         {

  164             if (Version == "01.00.00")

  165             {

  166                 // Install module permissions

  167                 InitModulePermissions();

  168             }

  169             return Version;

  170         }


  172         private void InitModulePermissions()

  173         {

  174             PermissionController permCtl = new PermissionController();

  175             ArrayList arr = permCtl.GetPermissionByCodeAndKey(ModuleSecurity.PERMISSIONCODE, "");


  177             DesktopModuleController desktopMod = new DesktopModuleController();

  178             DesktopModuleInfo desktopInfo = desktopMod.GetDesktopModuleByModuleName("MyModule");

  179             ModuleDefinitionController modDef = new ModuleDefinitionController();

  180             ModuleDefinitionInfo modDefInfo = modDef.GetModuleDefinitionByName(desktopInfo.DesktopModuleID, "MyModule");


  182             try

  183             {

  184                 PermissionInfo pi = new PermissionInfo();

  185                 pi.ModuleDefID = modDefInfo.ModuleDefID;

  186                 pi.PermissionCode = ModuleSecurity.PERMISSIONCODE;

  187                 pi.PermissionKey = ModuleSecurity.PERMISSION1;

  188                 pi.PermissionName = "A custom permission";

  189                 permCtl.AddPermission(pi);

  190             }

  191             catch

  192             {

  193             }

  194             try

  195             {

  196                 PermissionInfo pi = new PermissionInfo();

  197                 pi.ModuleDefID = modDefInfo.ModuleDefID;

  198                 pi.PermissionCode = ModuleSecurity.PERMISSIONCODE;

  199                 pi.PermissionKey = ModuleSecurity.PERMISSION2;

  200                 pi.PermissionName = "Another custom permission";

  201                 permCtl.AddPermission(pi);

  202             }

  203             catch

  204             {

  205             }

  206         }

Note that this code references a class named ModuleSecurity, more on this in a moment.

At this point, when you enter the module settings page for any module of this kind you will see the custom permissions on the permission grid.

and this is how the permission table data should look now.

At this point we have all the infrastructe ready to start using these permissions on our custom module.
Here is a sample class the encapsulates then common needs.
- it defines the permissions definition constants (used in all access to the data)

   23         // Constants

   24         public const string PERMISSION1 = "PERMISSION1";

   25         public const string PERMISSION2 = "PERMISSION2";

   26         public const string PERMISSIONCODE = "MODULE_MYMODULE";

- the interesting part in is the contructor, where you define a varible / property pair to define all the permissions in a more easy way.


   43         public ModuleSecurity(ModuleInfo modInfo)

   44         {

   45             ModulePermissionCollection permCollection;

   46             permCollection = modInfo.ModulePermissions;


   48             ModulePermissionController permCtl = new ModulePermissionController();


   50             _permission1 = ModulePermissionController.HasModulePermission(permCollection, PERMISSION1);

   51             _permission2 = ModulePermissionController.HasModulePermission(permCollection, PERMISSION2);

   52         }


- and finally define a couple properties to wrap these permissions:


   56         public bool CanDoThis

   57         {

   58             get { return _permission1; }

   59         }

   60         public bool CanDoThat

   61         {

   62             get { return _permission2; }

   63         }

Now you can use that class on your module's code and do something like that:

    1 ModuleSecurity ms = new ModuleSecurity(this.ModuleConfiguration);


    3 if (ms.CanDoThis)

    4 {

    5  // do it

    6  ...

    7 }

You can see that without much effort you can provide a much richer configuration interface to your module configuration using builtin DNN capabilities, and take advantage of the gread security features the framework has right out of the box.


Michael Tobisch
Would be nice if the images could be brought back to this article...

Michael Tobisch Thursday, February 13, 2014 4:23 AM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out