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.
Structure
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.
Setup
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 }
171
172 private void InitModulePermissions()
173 {
174 PermissionController permCtl = new PermissionController();
175 ArrayList arr = permCtl.GetPermissionByCodeAndKey(ModuleSecurity.PERMISSIONCODE, "");
176
177 DesktopModuleController desktopMod = new DesktopModuleController();
178 DesktopModuleInfo desktopInfo = desktopMod.GetDesktopModuleByModuleName("MyModule");
179 ModuleDefinitionController modDef = new ModuleDefinitionController();
180 ModuleDefinitionInfo modDefInfo = modDef.GetModuleDefinitionByName(desktopInfo.DesktopModuleID, "MyModule");
181
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.
Use
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;
47
48 ModulePermissionController permCtl = new ModulePermissionController();
49
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);
2
3 if (ms.CanDoThis)
4 {
5 // do it
6 ...
7 }
Conclusion
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.