Associate Space Members to a Group #240
Description
Rationale
It is possible to configure permissions for group members to access an app, a page, a site.
❓Then, What is the problem?
Unfortunately, it is not easy to associate space members to a group automatically while the contrary is possible using binding.
🎯 What is the goal?
Thus, the suggestion here is to allow platform admins associate Space Members to a Group depending on the template permissions.
That means, it would be possible to add space members to a selected group automatically.
Then, this selected group can be used to allocate permissions for feature, apps, page, site access.
1. Functional Requirements
Top User Stories
List space admin & space members in a group
In order to ease the platform management (incl. permissions to access a page, an app, a feature), we suggest to add a parameter in the space template so:
- each space member can be automatically listed into a group I select
As for example, for a template called "Alpha", if I want space members related to a space template to access a knowledge base stored into a page.
Then I can select a group (previously created in the organization side for example)
Hence, any space members of a space associated to that template (when creating or updating) will have access to this page thanks to permission management.
OR in case I want all members of spaces associated to this space template "Alpha" to access a helpcenter or a feature or an app from the appLauncher
Then I can do the same for space members field in the template.
Precisions:
- Only 'technical' groups can be selected (spaces one are not suggested as it would mix the binding)
- When applying the space to another space template, then an update would be done to this selected group so previous members / admins are removed from the previous group selected for the space template
- Updating space memberships to a user update the membership to the group associated to the space template, unless the user is also member of another space using it
That means groups for space templates will be created in the groups management and spaces associated to a template will be created as subgroups of the space template's group they're associated to.
Impacts
Gamification
N/A
Notifications
N/A
Analytics
N/A
Unified Search
N/A
2. Technical Requirements
Expected Volume & Performance
No impact on platform performance or volume is expected.
Security
The existing security Model should remain as is and no security constraint is to apply.
Extensibility
N/A
Configurability
N/A
Upgradability
N/A
Existing Features
N/A
3. Software Architecture
Access
- The space template form will be updated to allow selecting the groups in which the space template will be member of.
Services & processing
The needed Behavior of nesting group members into another group is very useful for different concerns. The concrete example is Group binding which currently is synchronizing users which may use a lot of time switch the users count. This may even lead to incoherent data when the operation of synchronization is still in progress while the binding is removed in the meanwhile. Thus, the a synchronization mechanism to copy memberships of users to another group is not performant nor instantly made nor consistent.
The solution would be to logically add members of spaces into the designated group. This could be made (as for MS Active Directory), using the nested groups. This way, the operation is instantly made and the consistency is guaranteed. The nested groups has to ensure a transitive inheritance as well, which means that the members of a space can be added as member of a space template group which may be member of a designated group.
Please find in the following figure an example illustrating the new groups design, including a specific group for each space template:
The Membership Types inside spaces will be preserved. By example: so that Managers of Spaces will be included as Manager.
The Nested Groups inside a designated Group will be as follows:
- Source
Membership(Group+Membership Type) = the group members who will be automatically nested into a target group - Target
Membership(Group+Membership Type) = theMembershipto apply for designated users using the SourceMembership.
By example:
- Source
Membership=manager:/spaces/exo_tribe - Target
Membership=publisher:/space_templates/community
This way, all manager(s) of the Space eXo Tribe will be publisher of the Space Template Group Community.
To implement this Group Inheritance mechanism, we will need to automatically add Space Groups as Nested in the Space Template Groups (Each Space Template will have its own Associated Group). To do so, we will need to add a method to retrieve the space group Id for a designated Space Template. Thus we will add a method SpaceTemplateService.getSpaceTemplateGroupId(long templateId), which will automatically create a group if not existing.
The groups inheritance properties will be stored inside each group using the following properties:
nestedMemberships= SourceMembership(as described above)enclosingMemberships= TargetMembership(as described above)
For a space, the values to retrieve will be:
nestedMemberships = nullenclosingMemberships = "~:/space_templates/SPACE_TEMPLATE_GROUP_ID"
For a space template, the values to retrieve will be:
nestedMemberships = "*:/spaces/SPACE_GROUP_ID"enclosingMemberships = null
To ensure that Space and Space Template Group labels and properties remains immutable, a new mechanism inside OrganizationService will be added in order to allow decorate/change the retrieved Group/User/UserProfile from Store based on Plugins extensibility mechanism. This mechanism will be used to retrieve the Space Template and Space Group title, description and nested groups switch Social Storage.
The Decorator Plugins to implement in social will be:
@FunctionalInterface
public interface GroupDecoratorPlugin {
Group decorate(Group group);
}When retrieving the Space Group, the enclosingMemberships has to be computed/appended to the stored one (minus Space Template Groups) through a specific GroupDecoratorPlugin to implement in social using SpaceService. This way, the space group membership inheritance is ensured from Space to space Template Group.
The same way, a new Decorator has to be implemented to determine the SpaceTemplate enclosing group switch the new UI Group Selector.
Data and persistence
A new Database Field GROUP_ID will be added inside the Table SOC_SPACE_TEMPLATES which will hold the space associated template group Id. This field will not be mapped into the DTO and will remain readable through a special methis inside SpaceTemplateService.
The Group extra attributes used to manage the groups inheritance will be stored as any other Group attribute inside the PL IDM Identities Table which is similar to a map where we can add any Key/Value Pair.