1.7B Permission Access Level

   Permissions in Clarizen provide the ability to compartmentalize work items to allow only relevant, role related individuals the appropriate read/write capabilities.

The Permissions have been limited to individual role assignment.  Now, in addition to the Permissions previously available, we have added Permission Access Levels to increase ease and control.  

With this new enhancement you can manage Permissions on a group/profile level without the need for individual permissions.  

Group permissions is available for Workitems, Cases and customers.

Set up:

  1. Once your account is assigned to Controlled Availability, enable Clarizen Labs 17.3 ‘Permission Access Level’
  2. Add ‘Permissions’ field to relevant view/property card  – which is similar to the ‘Sharing’ you are familiar with on views and reports.
  3. Once the Permissions field is added, a user with full manager/owner/editor capabilities can assign any of the below to the ‘Permissions’
  • Group- users groups and predefined system groups (Admins, SuperUsers, External etc.)
  • Profile
  • Specific user

Determine whether they have read only or read/write Permissions on the work item

  • Editor=Read/write (same permissions as manager)
  • Viewer=Read (same permissions as Reviewer)


The new permissions are in addition to current permission and roles on the WI, cases and customers (project manager, resources etc.).

'Group_permissions.PNG

 

Work items Permissions Access Levels  

   Permissions set on a Work Item using this method cascade to all child Work Items that sit beneath it.
Please note: user, group or profile name will not be repeated in all child fields, however permissions are available as set forth in the parent object.
In cases where the group has sub group- same as reporting- the permissions apply only to the direct members of the group.

 

When in Basic mode

  • Internal users – As all internal users have basic permissions, the enhancement for internal users is only relevant for Editor Permissions

  • External users – In basic mode, the enhancement will affect both Editor and Viewer

When in Enhanced mode

Internal user + full license - The permissions are the same for the user, profile and group.

  • If granted on the hammock level, Item level permissions roll down to all sub WorkItems.
    • The child (sub item) permissions field does not show user/group/profile however the permission is active.
    • When granted on project ‘sub work-item’ and System Setting 3.2 Enhanced permissions project visibility is ‘enable’ - the user/group/profile can view the entire project. (If granted in the sub-system, the user will have access to view all levels above).
    • When in System Setting 3.3 Display related items is ‘show name’ user/profile/group access can view all related items (cases, predecessors, successors).
      This  access is limited to name only without view of content.
    • As current permissions allow - the user/profile/group can continue to view related files, resources, reviewers, groups, topics, and notes.Permissions_enabled.PNG

External user

Specific user has the same permissions as the internal user.

Users that are part of a profile or group –

  • When the user (in the profile/group) is assigned on the project level, the permissions roll down to the project sub items, and the user can see the sub items as part of the detailed work plan view (the user will not see the sub items in the relevant module).
  • When on the Global search, the user will see only the project (without access to the project’s sub items).   Therefore all searched should be done on the project level.
  • When in WI module the user will only see the project level.

 

 

General Information:

  • When you remove a user from the hammock, the user is removed from all related sub items. Unless the user/group has been added explicitly at a sub item level
  • A user with multiple permissions/role set (based on current profile or as part of a group in current profiles) gains access based on the highest permissions (editor over viewer)
  • Editor and Manager can manage the permission field on WI they are defined as editor/manager.

Filters:

A user with Viewer/Editor permissions will view workitem under the role ‘Mine’ in the module.
Two exceptions to the above rule are:

  1. When the user has permissions based on a Group or Profile – the workitem will not be in the view ‘Mine’ (because the user does not have direct permissions for the specific item).
  2. When an internal user has Viewer permissions on a project – the user will see the WI on the project module under the role ‘Mine’ (but this will not be visible Milestones and Tasks).

 

Cases Permissions access levels

The new permissions are in addition to current permission and roles

  • Upon creation
    • 'Owner'=case owner
  • When Case owner is deleted
    • No ‘Owner’ in ‘Permissions’ field

 

Customer Permissions access levels

As there were no permissions for Customer object, there is now an option to manage who can view or edit customer object, allowing even more scalable security for large organizations.

The new functionality is available for both Basic and Enhanced mode.

'All' - all internal group, receives 'Editor' permissions by default.

Technical account owner received 'Editor' permissions by default.

  • Upon creation:
    • no ‘Owner’ in ‘Permissions’ field
    • editor=all internal
  • When account owner is updated
    • owner=account owner
    • editor=all internal
  • when account owner is empty
    • No ‘Owner’ in ‘Permissions’ field
    •  

Advanced Configuration Options

A new link - ‘Permissions Definition’, enables one to add or remove permissions access levels for work items, cases and customer objects , to users, group and profiles as viewer or editor based on business rules.

permission_definitions.PNG

This new link allows to add Permission Access Levels automatically base on any property on the object or related item levels.

Few examples can be:

  1. Add Project’s related groups as viewer on the project level
  2. Add specific group as editor based on the project's type

It is also possible to copy permissions access levels between related objects such as from project to its related risks, or from a customer to its related projects.

To set this up simply run on relevant object or link:

  1. Select ‘New Item’ action
  2. NewObject= New Permissions Definitions
  3. Select $Entity based on the relevant entity you wish to run this on
  4. Select $Source based on the business rule
  5. To determine whether the resource will be granted as editor or viewer:
         
    1. Add ‘Role Mask’ field

access_level.PNG

    1. Add ‘PermissionsRole’ function
    2. In parenthesis add ‘Editor’ or ‘Viewer’

permission_role.PNG

Note:

  • Owner and virtual system groups such as admins, financial user, super users (when they are in their default role- viewer) cannot be added, deleted or copied using the configuration engine.
  • If a user, group or profile already has a link to the object, as specific role (viewer or editor) it cannot be edited to a different role. You will need to delete and add again with the new role.
  • No option to edit definitions from the Permissions field.
    • For example:  userA and userB are defined as viewers for projectX→
    • Then copied to related risk- Risk has userA and userB as viewers
    • Adding userC and removing userB
    • Unless there is a worflow rule that handles the deletion as well, this action will cause Related risk to include now userA, userB and userCso

 

 

Permission Access Levels Panel

Permission Access levels panel enables a comprehensive view of who has access to the items, which level, and how he got it.

The panel is available for all workitems, cases and customer as related panel including all users, groups and profiles which have permissions to this item, whether by direct role (such as owner or project manager’), granted permissions, or by inheritance from parent item, or aggregated from child item.

Each row represent user, group or profile, its access level (Viewer or Editor) and whether it was granted directly or inherited from another item.

 permissions_panel.PNG

 

 

Set up

Permission Access Levels panel is available to be added as related items in profile settings

Access_level1.PNG

 

 

  • Access Level displays the actual access level the user, group or profile has, and not necessarily what was granted directly for this item
    • For example: A user who was granted as viewer on a project, while his group was granted as editor, will be displayed as editor on the Access Level field, and as Granted= no, on ‘Granted’ field.
    • On workitems:
      • Owner, Project Manager, Managers - will be displayed as Editors 
      • Reviewers - will be displayed as Viewers
      • Resource - will be displayed as a Partial Editor on task and milestone and as a Viewer on  a Project
    • On cases:
      • All members in the case lifecycle - will be displayed as Editors 
      • Team member and reviewers - will be displayed as Viewers
    • On customers:
      • Account owner and technical account owner- will be displayed as Editors

Best Practices

  1. For executives, who mainly view items in Clarizen - create a group or a profile of all relevant users, and assign this group/profile using workflow rules to all relevant workitems, cases, customer, views or reports they need to view. No need to add them individually as reviewers anymore.
  2. In case a group of users need to be able to edit a case or workitem, and they are not managers of this case/workitem, you can create a group with those team members and add it as ‘Editor’.
    1. If they are managers on this case or workitem, once done, remove them from manager field.
  3. Group manager receives now the group permissions, no need to create a workflow rule in order to grant him permissions in addition to the group access level.
  4. User, group and profiles granted permissions using the new enhancements will not be added as followers to the item. In case the users need to receive notification from the item, add them as reviewers, and not in the Permissions field.
Have more questions? Submit a request

Comments

Powered by Zendesk