Admin/PermissionManagement

New to Permissions?

Before you go into detail Watch the Basic Permissions Video

Permissions Management

Cumulus Permissions are controlled using the following functionality:

• Account Features. These are controlled by Emersion at the core of our system. They grant access to certain functionality and cannot be modified by the user.
• Modules (Permission Groups). These control access to pages, or parts of a page within Cumulus (for instance, a particular tab).
• Base Powers. These control access to certain functionality within a page or tab.
• Account Groups: These control access to which Organisational Units have access to a collection of accounts.

In reality, the distinction between Modules and Base Powers is more complex than what is stated here, but these descriptions are a simple way defining and thinking about these controls.

How Configurable User Permission Interact

The following Diagram gives you an idea as to how the user configurable permissions of Modules, Base Powers and Account Groups interact.

Example of a Particular Interaction of Permissions

• In this example, we can see that the the Retail Service Provider has granted access to cumulus for their store dealers, who sign up customers and sell mobile phones.
• Two roles have been created. One role has been granted Modules and Base Powers, and this Role assigned to the Org Unit, so that the dealer can carry out their normal day to day functions.
• In addition, they have created another special role which will permit a dealer to order products, as they wish to restrict this to some dealers and not others, this role was also assigned to the Org Unit.
• An Account Group has been setup to group accounts by their geographic location, this particular account group is for Glen Waverley. Users assigned to the Glen Waverley Org Unit can only see Accounts in the Glen Waverley account group (remember, an Org Unit can only be assigned to one Account Group at this time). When a user in the Glen Waverley Org Unit creates an account, because of the link between the org unit and the account group, the account is automatically put in the Glen Waverley Account Group once the package is created, assuming the pkg has a contract (note: accounts can be moved in and out of account groups for those with sufficient access to specific parts of the system). You read more about this auto assignment in the Account Group setup page listed in this article.

Current List of Modules/Permission Groups and what they permit access to

• The following zip file list the available Permission Groups for use, and what each permission group will grant access to.
• Remember that if one permission does not grant access to something, another does grant access and you assign both to a role, "ALLOW" access will always trump "DENY".
• You may encounter a situation where you need two permission groups, and one permission group inappropriately grants access to a module, but you still need it because of it's other functionality. If this is the case consult with Emersion.

• File:Permission Groups Module Controller Action.zip

Current Base Power permissions and what they grant access to

• The following file lists all of the available powers and what they permit access to.

• File:Current Powers List.zip

Module and Base Power access management

For a demonstration on how to setup module permissions in roles, and powers in roles, then associate those roles with organisational units (which directly translates to staff) see the below;

The media player is loading...

Account Group Setup, Assigning Accounts and Org Units to Accounts

• Please follow the link to the main page on this topic Account Group Overview and Setup

Steps for Troubleshooting Missing Module Access

• Before you begin, you must consider what permissions are at play here. Is it really a Permission Group issue? Or is it an account feature, account group or base power problem? The article as a whole will help you determine this, but assuming you believe it is a permission group problem, here is how you can go about troubleshooting.

• In this example, Sally can see service identifiers against a service subscription, but she can't seem to mark them inactive.

• 

• If you move your mouse over the relevant tab, you'll see a URL pop up. This will come in handy later when you are tracking down the module/controller.

• 

• Find the the Roles assigned to the Org Unit that the staff member belongs to. Have a look at what Permission Groups/Modules have been assigned and make a note of them.

• 

• Using the file here, have a look at what each permission group can do, are they permitted access to service identifiers, and if so, what kind?

• File:Permission Groups Module Controller Action.zip

• Chances are, none of the permission groups have the relevant access granted. Remember the URL we saw before when we hovered over the Service Identifier Tab? We can use this URL to find the permission group we need in the spreadsheet.

• In this example, the Module was: Customer and the Controller: Service:

• 

• Filter these values in the spreadsheet. Looking at what's available, we can see here that the Service Identifier Permission Group is going to be our best bet.

• 

• Go ahead and assign the permission group to the role and test. In this example after the change, Sally now has access to what she needs.

•