(v1) .Permission Sets v2019.5

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 the 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.
• 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
• Ability to Edit Historical Crystal Reports
• 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.