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 in the DB:
db.getSiblingDB("{space-ID}") .getCollection("cdcm.permissions").deleteMany({});db.getSiblingDB("{space-ID}") .getCollection("cdcm.roles").deleteMany({});
(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.
Add Comment