Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Introduction
Users can belong to one or more groups. This is usefull to give users access based on their groups. As groups This feature allows for access control and the addition of metadata to users. Groups can be automatically provisioned from the IDP, as described here: explained in User ProvisioningWith that you can build Access control on to the Space and Files and Folders like described here, enabling:
Access control for spaces, files, and folders.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
More info on access control: https://unique-ch.atlassian.net/wiki/spaces/SD/pages/592871488/Knowledge+Base+Interface#Define-data-access-of-a-Space |
...
Metadata assignment for system-wide use
Group & User configuration resulting in user Metadata
Groups and users can have configurations that can be used for the prurposeserve various purposes, including:
Filtering the data via smartRules.
In prompts for adding knowleadge about the user for example the name or the Email address of the currently logged Data Filtering: Leverage smartRules to effectively filter data.
Personalized Prompts: Add contextual information about users, such as their name or email address, for dynamic prompts based on the currently logged-in user.
Custom claculations within 3rd party modules Calculations: Enable tailored calculations and logic within third-party modules.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
More info on custom calculations: Deployment of Hosted SDK Module |
...
API
Metadata for users and groups can be freely defined and set via API. managed through the API.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
For more details, see the documentation: Managing groups & group members via API |
As a Users can When users belong to multiple groups at the same time there is a defined way on how the users inherit Metadata from the groups:
The groups are sorted A-Z
The metadata is collected starting from “A” overwriting the the data of the groups that came before. That means the group Z would win out.
then the User configuration is added to the metadata and this supersides the data from before if there is a clash in naming.
Here is an example:
A user named John , metadata inheritance follows a specific process:
Alphabetical Group Sorting: Groups are sorted from A to Z.
Progressive Overwriting: Metadata is inherited starting with group "A," with each subsequent group overwriting conflicting metadata from earlier groups. This means that metadata from group "Z" will take precedence over all others.
User-Specific Configuration: Finally, the user-specific metadata is applied, overriding any group metadata in case of conflicts.
Example of Metadata Inheritance
Here’s an example to clarify how metadata is resolved when a user belongs to multiple groups.
A user named Jon belongs to the Group “A” and to the group “B“ and they have the following configurations.
Code Block |
---|
Jon:
userConfiguration: {
location: "New York"
favouriteFood: "Pizza"
}
Group A:
groupConfiguration{
location: "London"
headMaster: "Tom"
additionalInfo: "Co-Working Space only"
}
Group B:
groupConfiguration{
location: "Zurich"
headMaster: "Michelle"
bestBar: "OleOle"
}
|
This would result in the follwing metaData for a user: Resulting Metadata for Jon
Code Block | ||
---|---|---|
| ||
Jon: { "Metadata": { "location": "New York", // From userConfiguration (overwrites group) "favouriteFood": "Pizza", // From userConfiguration "additionalInfo": "Co-Working Space only", // From Group A "headMaster": "Michelle", // From Group B (Group B > Group A) "bestBar": "OleOle" // From Group B } } |
Conclusion
Using group and user metadata, you can:
Streamline access control.
Enhance system customization.
Build intelligent, metadata-driven features.
...
Author |
---|