Difference between revisions of "Admin/PermissionManagement"
From Emersion
(→Permissions Management) |
|||
| Line 5: | Line 5: | ||
== Permissions Management == | == Permissions Management == | ||
| − | + | Access to features and functionality is controlled using the following elements: | |
| − | + | '''Controlled by Emersion''' | |
| − | |||
| − | |||
| − | |||
| + | * Account Features: These control access to the core and optional modules. Access is granted to a service provider account based on your subscription. Refer to your Emersion Customer Agreement for a list of what your company subscribed to. | ||
| − | + | '''Controlled by Emersion users''' | |
| + | |||
| + | * Modules-based Permissions (often referred to as Permission Groups): Module-based permissions control access to 2nd-level menu items, or sections of a page within Cumulus. For instance module-based permission can enable or disable access to a particular sub-tab under a Menu item. | ||
| + | * Base Powers: Give more granular access controls over certain functionality within a single page, tab or function. For example, base powers will goven access to fields and control access to read, write or delete. | ||
| + | * Account Groups: Account groups are not used to control functionality in any way. Account groups are used solely to grant or deny access to a collection of child accounts. This is often used when a service provider wants to prevent a user to being able to access the entire customer base, but provide access to a sub set of customers. | ||
| + | |||
| + | Module permissions and base bowers can become complex when looking at finely grained access control. However these descriptions are a simple and accurate way of describing these two mechinisms of controls. | ||
| + | |||
| + | '''Remember; | ||
| + | |||
| + | ''''If you want to control access to Features, functionality, read and write access, use module-based permissions first, then refine the control further with Base Powers. | ||
| + | If you want to control access to customer accounts, use account groups.'''' | ||
== How Configurable User Permission Interact == | == How Configurable User Permission Interact == | ||
Revision as of 17:48, 4 September 2015
Contents
- 1 New to Permissions?
- 2 Permissions Management
- 3 How Configurable User Permission Interact
- 4 Example of a Particular Interaction of Permissions
- 5 Current List of Modules/Permission Groups and what they permit access to
- 6 Current Base Power permissions and what they grant access to
- 7 Module and Base Power access management
- 8 Account Group Setup, Assigning Accounts and Org Units to Accounts
- 9 Steps for Troubleshooting Missing Module Access
New to Permissions?
Before you go into detail Watch the Basic Permissions Video
Permissions Management
Access to features and functionality is controlled using the following elements:
Controlled by Emersion
- Account Features: These control access to the core and optional modules. Access is granted to a service provider account based on your subscription. Refer to your Emersion Customer Agreement for a list of what your company subscribed to.
Controlled by Emersion users
- Modules-based Permissions (often referred to as Permission Groups): Module-based permissions control access to 2nd-level menu items, or sections of a page within Cumulus. For instance module-based permission can enable or disable access to a particular sub-tab under a Menu item.
- Base Powers: Give more granular access controls over certain functionality within a single page, tab or function. For example, base powers will goven access to fields and control access to read, write or delete.
- Account Groups: Account groups are not used to control functionality in any way. Account groups are used solely to grant or deny access to a collection of child accounts. This is often used when a service provider wants to prevent a user to being able to access the entire customer base, but provide access to a sub set of customers.
Module permissions and base bowers can become complex when looking at finely grained access control. However these descriptions are a simple and accurate way of describing these two mechinisms of controls.
Remember;
'If you want to control access to Features, functionality, read and write access, use module-based permissions first, then refine the control further with Base Powers. If you want to control access to customer accounts, use account groups.'
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.
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.
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?
- 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.
