Permission Sets

Summary

'Permissions' and 'Roles' are often thought of as a One to One relationship. For example, a Role of 'Admin' and a Permission Set of 'Admin'. This can mean a massive number of both that must be created if there are pieces of the application that the Administrator wishes to restrict from a User group. A more effective way of handling this is to create a Permission Set that manages a specific function and then assigning that Permission Set to the appropriate Role as needed. Said another way, Permissions are most effective when used to disallow single or small sets of items, rather than to explicitly allow all sets of an item.

For example, the User should examine allowing a section of the application to a Role. This Role is the 'Example Role'. The 'Example Role' has a specific business role that must be controlled so the User cannot access some sections of the application but for other sections, access is desired. This 'Example Role' should have the following rules:

1. 'Example Role' should be able to access the CustomerCenter.

2. 'Example Role' should be able to access the Knowledgebase.

3. 'Example Role' should be able to access Service Desk: Requests, however, Example Role should NOT be able to 'Delete Selected'.

4. 'Example Role' should NOT be able to modify Requestor.

In this case, the Best Practice of Permission Sets for Example Role could have five Permissions assigned to it. By taking this incremental access approach to Permissions Sets, an Admin can guarantee that even organizations with a large number of Users only access the portions of PCR-360 that are allowed to specific User groups and management of Roles, and Permissions becomes easier in the long term.

Permission Mindsets

Types of Permission Granting

There are two different ways permissions within PCR-360 can be given:

• Explicit: The User has specific access as defined by a specific Permission.

  • Example: The User specifically has access to the Cable Menu Option.

• Implicit: The User has specific access as defined by the default behavior of their Permission Set.

  • Example: the User has a Permission to the Services Menu Option, because there Permission Set is defined to allow access by default, and no Explicit Permission restricts this access.

Default Behaviors

There are three different default settings that can be applied across PCR-360:

• Read: By default, Users with this Permission Set will have Read Only access.

• Deny: By default, Users with this Permission Set will have No access.

  • Please see our FAQ if your Organization is using this style.

• Read & Write: By default, Users with this Permission Set will have Read and Write access.

When Permissions Conflict

It is possible for a User's permissions to come into conflict with each other depending on the Roles they are assigned, and how those Roles are setup:

• If a User has been explicitly allowed functionality, they will retain that functionality regardless of what other Permission Sets might indicate.

• If a User has been explicitly denied functionality and does not have an explicit grant, they will be denied that functionality regardless of what other Permission Sets might indicate.

• If a User has been implicitly allowed functionality and does not have an explicit grant to deny access, they will retain that functionality regardless of what other Permission Sets might indicate.

• If a User has been implicitly denied functionality and has no other Permission Set that explicitly or implicitly allows that functionality, they will be denied that functionality.

Admin Privileges

Simple Admin only Items:

• Access to Form Permission Builders

• Access to Grid Permission Builder

• Access to the Ad hoc Query Builder

• Ability to create Global Events in the Calendar

• Access to all Historical Crystal Reports (deprecated)

• Ability to Assign/Edit Historical Crystal Reports (deprecated)

• Ability to Add Crystal Reports to a Form (deprecated)

• Access to all Saved Custom Reports

• Ability to Assign/Edit Saved Custom Reports

• Ability to Add Custom Reports to a Form

• Ability to Add Custom Reports to a Grid

• Ability to Edit the Menu

• Ability to Approve Knowledge Base Articles

• Ability to Delete Service Desk Actions

• Access to the Manage Reports link on the form Options menu

• Access to the Manage Validation link on the form Options menu

• Ability to display RECIDs on grids

Additional Items that depend on a Configuration Option:

• Ability to Manually edit charges - MODIFY_CHARGES_WITHOUT_SERVICE_DESK

• Ability to Modify Serial Numbers on Equipment - MODIFY_SERIAL_NUMBER

• Ability to Edit Remarks - REMARKS_EDITABLE

• Ability to Override Billing Groups on Services - MODIFY_CHARGES_WITHOUT_SERVICE_DESK

• Ability to Complete/Delete workflow with configuration specifies - SD_WORKFLOW_PERMISSIONS

Privileges blocked to the Wiki?

When a Permission Set is set to "Deny" by default for "Menus & Pages / Urls", any User who uses that Permission Set will be denied access to search the Wiki. This can be easily corrected by adding Permissions to the Wiki Specific URLs.

Add the following Permission to the impacted Permission Sets:

• Page: Default

• URL: wikihelp

• Allow: yes

Once applied, these Users will be able to access the Wiki.

How to Set Permissions for View Cable Path, History Report, and 360 Search Results?

Overview

If when attempting to view a Cable Path, view the History Report, or perform a 360 Search, and the User receives a Permissions Error instead of the desired results, there is an easy way to fix this.

Note: The User will have to log out and log back in to receive the updated Permissions once they have been corrected. 

Granting Permissions for View Cable Path

1. Open the Permission Set used by that User, click on the Pages/URLs tab and click the  button.
   

   

2. The Page should be cabling and the URL should be view-path

3. Leave the Permission dropdown at Allow. 
   

   

4. Click the  button to save the Permission change.

Granting Permissions for History Report

1. Open the Permission Set used by that User, click on the Pages/URLs tab and click the  button.
   

   

   
   

2. The Page should be core and the URL should be audit

3. Leave the Permission dropdown at Allow. 

   

4. Click the  button to save the Permission change.

Granting Permissions for 360 Search Results

1. Open the Permission Set used by that User, click on the Pages/URLs tab and click the  button.
   

   

   
   

2. The Page should be core and the URL should be 360

3. Leave the Permission dropdown at Allow. 
   

   

4. Click the  button to save the Permission change.

Privileges blocked to the Wiki?

When a Permission Set is set to "Deny" by default for "Menus & Pages / Urls", any User who uses that Permission Set will be denied access to search the Wiki. This can be easily corrected by adding Permissions to the Wiki Specific URLs.

Add the following Permission to the impacted Permission Sets:

• Page: default

• URL: wikihelp

• Allow: yes

Why can't I access a standard PCR-360 feature?

Overview

Some PCR-360 functionality becomes inaccessible for Organizations using the Deny default Permission style of Permissioning. These features include:

• WIki Access

• Cabling Report

• 360 Search

• Executing SQL Query (via AdHoc Grids)

How to Update Permissions

This is because these features do not have direct Menu/URL Access, and require some additional steps to grant access to when Permissions are denied by default.

1. Navigate to Admin > User Management > Permission Sets.

2. Open the desired Permission Set to update.

3. Click on the Pages/URLs tab.

4. Click the   button.

5. Fill out the below form as follows:
   

   

   
   Page: core
   URL: See the Blow Reference
   Permission: Allow
   

6. Click the button to save the updated Permission.

Feature References