Working with Permissions

Navigation: Administration > Permissions >

ABACUS projects can have role-based permissions set for every element within the repository. Specifically, fine-grained Create-Read-Update-Delete (CRUD) permissions can be set at the 'object' (i.e. component or connection), view and attribute (i.e. property) levels.

For more information on how to upgrade an existing ABACUS file using the previous permissions, click here.

Overview

ABACUS provides fine-grained, role-based CRUD permissions to control the access for multiple users to the stand-alone or collaboration project. It is important to note, permissions are optimistic by nature and so long as at least one user group a user is assigned to has the required permission, they will be given access.

Note

To configure permissions in an ABACUS project the user needs the Administrator feature. Only Administrators can enable this capability, or any user when the project has no Administrators. Click here for more information.

Permissions can be set for the architectures, component and connection types, properties (via their types), templates, viewpoints and diagrams, catalogues, matrices, charts, 3D views and dashboards. When permissions are set for a component or connection type all the instances of that type in any architectures in that project 'inherit' those permissions. Likewise, when a permission is set for a property of a component or connection type, the given property on the component or connection instances in any architectures in that project 'inherit' those permissions. Accordingly, certain permissions will be applied to the views on which those elements exist. When the permissions are set for a diagram, the view and/or the contents of the view itself have various permissions applied to it.

Permissions can not be adjusted for specific instances of an architecture's elements, e.g. you can't make one Application component updateable yet another not. To effectively achieve these 'domain specific' permissions however, the Administrator can set up specific element types for the given domains, e.g. component types 'Application - CRM domain' and 'Application - HR domain', and then enable the permissions for each type accordingly. You can make specific Grouping types for each domain and then add or remove update permission for the domain-specific group type and this will configure creations within and deletions from that Grouping but not update of the children. Of course if the domain-specific Grouping was hidden by removing read permission then the children would be hidden and thereby non-updateable. Alternatively, if views (rather than explorer) are used primarily to manage/view your repository, a given view for each domain could be established, and then the Administrator could set the permissions for each view accordingly.

Setting permissions

Permissions Management

When operating the permissions toolwindow, there are functionalities and behaviour to take note of:

•Administrator privileges are required in order to access and operate.

•Entities which observe their permissions from a parent type will not be editable and display in a disabled state.

•Selecting cells while holding Shift will allow you to select all cells between the previously selected cell.

•Selecting cells while holding Ctrl will allow you to maintain the previous selection of cells.

•Checking/unchecking a highlighted cell will check/uncheck all other highlighted cells if any.

•The rows beneath the user groups with the [default permissions for children] text represent the permissions the children of the entity will inherit.

•Permissions in bold are overriding their inherited permission.

•Individual read and update permissions with a red exclamation next to their checked value indicate permission warnings.

•Where applicable create, delete and creator can delete permissions will be unchecked and disabled when the update permission is unchecked for the edited usergroup.

Note

Create permission governs also when you can copy an element. Accordingly, to be able to copy an element requires Create permission for all its children (since to copy the element means copying everything below it). Removing Update permission from an element removes the ability to modify the type itself, even if the user has configurer access and also removes Update permission for all its properties. A parent element must have Update permission to be able to Create any children elements or Delete its existing children elements. Delete permission for an element also requires Delete permission for all its children. Delete permission for components also requires Update permission of all the attached connections. Removing Delete permission from an element removes the ability to delete the type itself, even if the user has Configurer access. Finally there is an option to set Creator can delete under the same circumstances as the ordinary Delete permissions which means the creator of the elements of those component/connection types are able to delete them even if they don't have ordinary delete permissions (This option is disabled if the ordinary Delete option is checked).

Note

Under circumstances where a user does not have permission write access to a Super Type though has write access to a child type that inherits the super type, the inherited properties will still be visible and available for use. This can be helpful to hide super types from regular users while still giving access to the super types properties.

Note

Properties that have had the Update permission removed are shown in italics in the Properties window and their values cannot be updated by that role. Also, the ability to modify the details of a property (e.g. the name, units) requires both the Update permission on the property and Configurer access.

Note

While you can set the CRUD permissions directly for a diagram, it should be noted that the permissions of the elements on the diagram may affect the permissions for the view itself. For example, if there is even just one element on the view that has had its Read or Update permission removed then the diagram will have its Update permission removed. This is because; a) the elements on the view that have had their Read permission removed won't be shown on the view leaving 'white space' where you might otherwise place some new elements if the view was updateable, and b) the elements on the view that have had their Update permission removed could then have other elements dropped onto them to become children if the view was updateable. Also, Create and Update permission for a diagram requires that all the elements on the view have the Read permission and the components have the Update permission (this is because to move a component onto another component, you must be able to update it since it will become a child).

Resolving Permission Warnings

When setting permissions, aside from collections that don't own their own set of applied CRUD, read or update access is required on the parent to be able to have read or update access on a child of the parent respectively. In cases where read or update access has been set on permissions on child objects that correspond to its parent permission, a warning will occur, and be represented in the form of a red exclamation mark next to the specified access on the permission. It is recommended that these warnings are resolved so that the warnings are cleared, but it is sometimes viable to be left in this state if the configuration of the user groups is set up to have read and / or update access to the parent entity through another user group.

To resolve a permission warning

1.Select entity in the explorer toolwindow you wish to resolve a permission warning for.

2.Double-click the exclamation mark beside the permission.

3.Review and check the permissions to add to resolve the warning.

4.Click OK.

Note

On opening of the dialog, the minimum options required to resolve the warning will be pre-selected indicated by the enabled options. Disabled options are pre-existing permissions and cannot be removed in this dialog.

Tip

Where applicable, a All children at this level option will be provided to let you choose to inherit the permission for non-overriding children for the parent.

Resolving Permissions