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:
Code Block db.getSiblingDB("{space-ID}") .getCollection("cdcm.permissions").deleteMany({});Code Block db.getSiblingDB("{space-ID}") .getCollection("cdcm.roles").deleteMany({});
(Re)start the CDCM application with this version.
Helm Chart v 0.1.8
- cleaned
Cleaned up MongoDB values:
- “replicaCount” was moved up one tier and is no longer under “hidden”.- “
useStatefulSet"“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
...
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 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
...
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
General Info:
There are now two types of roles: space-scoped and configuration area scoped
There are now two types of permissions: space-scoped and configuration area scoped
Permissions can only be added to roles of the same scope
There are 4 types of permissions: MAINTAIN (contains create, modify and delete), modify (only update, no create), READ (see explanation below) and DELETE
The association of a role to a scope (meaning a specific instance of a space or a configuration area) happens in the auth provider and works like this:
Space scoped role
Two terms: <space id>.<role key>
Configuration area scoped role
Three terms: <space id>.<configuration area id>.<role key>
<configuration area id> == “*” means all configuration areas
Read access works like this:
there are only two levels of read access
READ Space permission (space scoped permission) → read all content of the space (where you have a role with this permission of course) except the content of confidential configuration areas
READ configuration area (configuration area scoped permission) → read content of confidential configuration areas (where you have a role with this permission of course)
Role administration: All spaces come with a built in role that has the key “roleAdmin”
space scoped role
has two permissions: READ for this space, MAINTAIN roles
this means you can give a user in the auth provider this role by giving them this role string: “<space id>.roleAdmin”
Concept type specific permissions:
for each concept type there are specific permissions to allow fine control
configuration area scoped
three permissions for each concept type:
MAINTAIN concepts with type
DELETE concepts with type
MODIFY protected state transition: state transitions can be marked as protected, this means the user needs this permission to do those transitions
Viability tests with Atlas
...