Recently we've introduced an additional security capability to Targetprocess making it possible to control user access permissions to entities in a more precise and flexible way.
Direct Access to Entities preview is released in v3.13.1.
By default, the feature is toggled off now. If you would like to test it please request Support Team to activate it for your account.
Project and Team Access Compared with Direct Access to Entities
In general, permissions to view entities in Targetprocess are defined by Project and Team membership.
Permissions for allowed actions are defined with the Add, Edit, and Delete settings of a user's Role.
With Direct Access to Entities, it is also possible to grant a user with access permissions to selected Project or Team items. These items become visible, while the rest of the project/team data remains hidden. Users are added directly to entities, and not to project/team member areas.
Permissions for allowed actions are defined by selected Direct Access mode: Can comment, Can edit, or Can grant access.
All types of permissions complement, not overlap each other. An action is allowed to a user when it is allowed by whatever Project, Team, or Direct Access permission.
When is Direct Access useful?
Direct Access to Entities helps to track confidential data in a single Targetprocess instance. Sensitive information can be precisely shared with involved key people, rather than broadly. People who need to collaborate may come from any part of a company: external projects, teams, departments. Independent contractors are one more example. Just an active Targetprocess user account is required for access and collaboration.
Direct Access to Entities can be used in the HR, Legal, Financial, Accounting, and Customer Relations company departments for collaboration with other organizational units.
How to Manage Direct Access to Entities?
Access permissions are managed by Administrators and (since v3.13.3) Creators of entities. Access is granted and revoked via dedicated UI control. The control is displayed on detailed entity views, below the Assignments area.
In the future, we'll likely delegate Grant Access permissions to Project/Team managers and users with Edit permissions over entities. Please share your feedback with us should you want to get this capability allowed or prohibited.
Direct Access permissions can be also controlled by Automation Rules. External integration services set permissions via REST API with the System User token.
- Epics, Features, User Stories, Tasks, Bugs, Portfolio Epics
When activated, Direct Access to Entities UI control appears across all supported entities and processes in your system.
Access can be granted to items from both regular and private projects.
Access can be granted with Can comment, Can edit, and Can grant access modes.
Users are added to entities one by one. Can comment mode is set for new users by default. It is possible to switch access mode for already added users. To revoke access please click on the red trash can icon.
How it Works for End-Users
Entities with Direct Access become available to viewers by web browser links (URLs). Entities also appear on views (as cards), and in Search results.
When a User is granted with Direct Access to an entity, its Project becomes available for selection in project/team selectors on views.
End-users don't see UI controls for Direct Access permissions settings and don't see who else has Direct Access to shared items.
Users with Direct Access can be assigned as responsible to work items.
If Direct Access is provided to a parent entity only (for example, a Feature or an Epic), a user won't get access to nested items (User Stories, Tasks, Bugs). Corresponding hierarchy tabs will be blank. Should you require inherited access to child hierarchy items, please add your feedback to corresponding idea on our Service Desk.
API for Permissions Management
Access is granted/removed by creation/deletion of the EntityPermission resource. We explain how to work with it in our Developers Guide: Direct Access to Entities.
Automation rules may set Direct Access permissions. Examples:
- Set Can comment as default access mode for newly added users.
- When a Request in a private product is created via Service Desk, and Requester-Creator has Targetprocess user account, grant Requester-Creator with Direct Access to the Request via Targetprocess views.
- When access to a high-level planning item is granted, populate it to all nested items.