Dynamicweb CMS

Built-in modules like the News module offers the opportunity to limit access of individual users and groups to certain categories and allowing them to perform only a limited set of actions. Setting up these permissions is a standard feature and is done on the user and group edit page on the Modules tab in the user administration.

Most custom modules for Dynamicweb that I’ve seen, offer only the opportunity to set the Access attribute for this module. This attribute can be set to True, False or Inherit and is a standard feature for all modules registered in the Module table. This setting defines weather the module should be displayed to the current user on the Modules page.

Of course it's not for all modules that it makes sense to extend the functionality, but when dealing with categorized content, my experience is that this feature is frequently requested.

Suppose you've developed a small CRM module to store your customers and classify them by their engagement in your business. You may have three classifications for you customers: A, B, and C where A customers have the most engagement and C have the smallest. A customers enjoy special attention and high discounts and thus you don`t want all your sales representatives to have access to classify their own customers as A customers. This feature should only be available to the sales manager. Then you would need to limit the access to A customers to user.

The illustration shows a simple example of the data model. The Customers table contains the all customer information, and CustomerClassification contains the classification captions to categorize your customers by.

The first thing to do is to modify the record containing your module registration in the Module table. This is in order to make the Users module aware of what you want to limit access to.

This registration enables Dynamicweb User management to iterate through the table storing the categories, displaying the records that match the criteria.

Supposing your module record is correct, this registration would produce the following list in User management.

In our example only the sales manager should be able to classify customers as A customers. In Dynamicweb terms this means that all other users should be denied access to this category. This is done by granting them access to all categories other than the A category. Not making any access specification for the sales manager grants her unlimited access to all categories.

You would want your code to be able filter away the content that current user has no access to, and the Dynamicweb API provides functionality to support this with the HasAccess function located in the Base namespace.

This function lets you interact with the permissions setup in three ways providing you with the following information:

1. Does the current user have access to the module

2. What actions are available to the current user - Access, Create, Modify, Delete

3. Which objects in relation the category records are available to the current user

We made some changes to the module record earlier, so let's start by looking at how we use these.

Suppose that in your CRM module when displaying customer details you would want a drop down to easily choose the customer’s classification. Not all options should be available to all users as only the sales manager should be able to classify A customers.

HasAccess() takes two arguments, strKey and strValue. To display only the allowed records, strKey must be ModuleSystemName followed with "Categories", in this case "MyCrmCategories". strValue must be the value stored in the field which name is stored in ModuleFieldID in the Module table, in this case CCID.

When adding options to your drop down list, you would use something like this:

Dynamicweb evaluates the parameters against the current user’s permissions settings and returns True if permissions is granted, otherwise False.

To use HasAccess() to control which features are available from this module to current user, the strKey argument should be passed as ModuleSystemName followed by feature name. strValue must be an empty string. Available feature names are:

• Create

• Edit

• Delete

You can easily implement the feature names in you GUI as well as your code. If you want to control which users are allowed to press the Create button, you do something like this:

Passing only the ModuleSystemName returns a Boolean value indication weather the user is granted access to the module or not.

Implementing this permission control is easy and doesn't take much time when developing new modules. And offering your customers the opportunity to limit their employees' potential of messing things up always makes a happy customer.