Breaking changes

The permission rework changed the schema of permissions and roles and the relation between the two.

For newly created spaces with this version of the application, the roles and permissions are correctly set up:

• The new space is automatically set up correctly with the new permission and role structure and comes with a built-in Role admin role (role key: “roleAdmin”).

For existing spaces, you need to reset the roles and permissions:

• Delete all permissions and roles (either before the update or directly in the DB).

• (Re)start the CDCM application with this version.

Helm Chart v 0.1.8

• Cleaned up MongoDB values:

  • “replicaCount” was moved up one tier and is no longer under “hidden”.

  • “useStatefulSet” now defaults to “true”.

• added proxy and resource options to JAVA_OPTS

• added more comments to the values.yaml

Single Page Application V 0.1.8 - New Features

All UI initiated database transactions provide feedback to the user now showing a work progress indicator and putting the application to modal mode as long as the transaction needs to finish.

UI changes:

• Storage location UI

  • Added “Storage Location” section in the UI

  • Removed “Friends” section from the UI

  • Removed “Consumers” section from the UI

Storage locations are a generalized approach to manage the storage of configurations. This includes OSLC Configuration Providers, which were formally managed by “Friends”, as well as other software applications or even physical locations. Also, OAuth1.0a consumer are now also managed by storage locations instead of the “Consumers” section.

• Added Delegated UI definition in concept type editor for configuration and component

• Added Delegated UI preview feature to test the CDCM delegated UI as it would appear in other applications

• Configuration Browser

  • Full view option

  • CI browser was brought more in line with the agreed upon concept (e.g. config item title instead of configuration title as the first column)

Where-Used

• Where-used can be started from anywhere in the platform

• Where-used can have one search object and the following options can be applied for the result:

  • Direct usage or usage along the path

  • Selection of the target concept (configuration or component)

  • Selection of a target concept type

  • Selection of a target concept instance (result will only include concepts of this instance)

  • Selection of target property filters

    • Only properties that have “Where-Used can be filtered by this Attribute" enabled are selectable here

• Circular reference check was added

  • prevents existing circular references from breaking the where used with full path

  • prevents creation of circular references for new configuration items
    

Known issue: components cannot be selected as a target concept instance at the moment. A bug ticket was already created.

Permission rework

Permission rework was implemented according to the agreed upon concept.

Key parts include:

• Simplified READ access: Read Permission for space mean read access to everything except confidential config areas and their content

• Roles are identified via role key: makes it clearer what roles the user has in the auth provider

• Differentiation between space and configuration area scoped roles and permissions

• Maintain (create, update, delete) Permissions specific for each concept type

Caveat:

• Concept Type based permissions and some other permissions (e.g. permissions regarding storage location) are not always visible in the UI (e.g Create button is not disabled even when the user does not have the permission) but the backend always handles the permission correctly

Viability tests with Atlas

Some tests were done where CDCM was connected to a Atlas. An initial smoke test revealed no issues.