Role-based access control for development packages

The Development Package tool provides role-based access control to enforce what actions users can perform on individual artifacts within a development package.

Role-based access control for a development package is enabled by assigning at least one role to a development package. With that, only users that have one of these roles assigned can access the development package and its artifacts. In case no role is assigned to a development package, all users that have access to the corresponding Cockpit tools can work with the development package and its artifacts.

Note that roles assigned to a development package control the design-time access to the development package within the Cockpit. In contrast, roles assigned to individual artifacts control the run-time usage of these artifacts (for example launchpads and applications).

The role-based access control for development packages is independent of the access control to the Cockpit tools that are used to work with the individual artifacts contained in the development package. This means a user needs to have roles assigned that grant both access to the development package and the corresponding Cockpit tools.

In order to allow for flexible user management, it is recommended to use separate sets of roles to control access to tools on the one hand and to development packages and their artifacts on the other hand.

Permissions for user roles

The Development Package role-based access control provides the following access levels:

  • Read

  • Edit

The intersection between the roles assigned to the user and the roles (with their access levels) assigned to the development packages control the access of the user to the development package and its artifacts.

Role-based access control will not be applied to the system user admin and to users that have a Global Admin role assigned.

Role-based access control and artifact relationships

Many artifacts in the Neptune DXP - Open Edition system are linked with each other. For example APIs link to server scripts or tables, tile groups to tiles, etc. While users may not have access to specific developments packages, the references of other artifacts, to which the user has access, will still show the name of the referenced artifacts to which the user has no access. For example, an API operation pointing to a server script will still show the name of the server script even though the user has no access to the development package that includes the server script.

Permission example scenario

The following example scenario illustrates the interplay between the role assignment to the development package and to the user.

For this example scenario we assume the following setup:

  • User role dp_read is assigned to user user_a and to the development package dp_example with access level Read.

  • User role dp_edit is assigned to user user_b and to the development package dp_example with access level Edit.

  • User role dp_other is assigned to user user_c and to no development package.

This setup results in the following access to dp_example and app_example:

  • User user_a can

    • display dp_example and app_example.

  • User user_a cannot

    • edit or delete dp_example

    • assign or remove artifacts to/from dp_example

    • edit or delete app_example

  • User user_b can

    • view and edit dp_example

    • assign and remove artifacts to/from dp_example

    • edit app_example

  • User user_c can

    • view the reference/name of app_example in an accessible tile that has this application configured as its action

  • User user_c cannot

    • view dp_example in any development package lists

    • view dp_example in any application lists

Related topics