How to handle CapabilitySets which include Capabilities which may not be deflined yet.
- Viktor Gema
- 1 Spike Overview
- 2 Problem Statement
- 3 Deliverables
- 3.1 Option 1 Postpone the UI events in the database to process them later, after processing all backend modules' events.
- 3.2 Option 2 Rearrange the application descriptor so that UI module capability events are sent only after all backend module events have been sent:
- 3.3 Option 3 involves creating postponed jobs for the capability events that have not been processed, and triggering them again when a new application is installed.
- 3.4 Option 4 involves creating a mapping table for capability sets to capabilities that do not yet exist.
- 4 Implementation for option 4
- 4.1 Statements
- 5 Conclusion
Spike Overview
JIRA ID: EUREKA-90 How to handle CapabilitySets which include Capabilities which may not be deflined yet.
Objective: EUREKA needs to manage a capability set that includes capabilities that do not yet exist on the platform.
Problem Statement
The UI module's descriptor includes a permission set with permissions from other backend modules. When the application is entitled, UI modules can be installed earlier than backend modules, as the process occurs asynchronously via an event from Kafka. In this scenario, EUREKA does not create a capability set and skips this event because it lacks sufficient information to create it and associate it with existing resources in Keycloak. OKAPI checks permissions at runtime and does not make any pre-installations.
Deliverables
Option 1 Postpone the UI events in the database to process them later, after processing all backend modules' events.
The approach requires that capability events for UI modules are not sent until all backend modules have been processed, and a delay or confirmation event from mod-role-keycloak indicates that all backend modules have been installed.
Pros
This can be quickly implemented to resolve the issue for phase one, especially when we will have a couple of large applications installed on the EUREKA platform.
Cons
This approach does not handle proper permissions set when one of the permissions would be in another application and would be installed late.
Option 2 Rearrange the application descriptor so that UI module capability events are sent only after all backend module events have been sent:
The approach involves rearranging the processing of modules to send all UI modules only after all backend modules have already been processed.
Pros
This can be quickly implemented to resolve the issue for phase one, especially when we will have a couple of large applications installed on the EUREKA platform.
Cons
This approach does not handle proper permissions set when one of the permissions would be in another application and would be installed late.
Option 3 involves creating postponed jobs for the capability events that have not been processed, and triggering them again when a new application is installed.
If we encounter an issue while processing a capability event and cannot proceed correctly, we will create a postponed job from this event and store it in the database. The postponed jobs will attempt to rerun once the mod-roles-keycloak receives another event indicating that a new application has been installed or updated. It is essential to ensure that these jobs start only after the application installation has been completed.
Pros
This approach would handle all possible cases where the UI modules have permission sets with permissions from other backend modules, which could be defined in other applications.
Cons
The approach will require a long time to implement.
Option 4 involves creating a mapping table for capability sets to capabilities that do not yet exist.
If mod-role-keycloak receives a capability event but cannot create a capability set because some capabilities are missing, it will still create a capability set and add a record to the mapping table indicating that this capability set is associated with another capability, along with the capability name. When we receive another capability event, we will create it and check the table to see if there is a capability set associated with it. If there is, we will associate the capability set with it and remove that item from the mapping.
Pros
This approach would handle all possible cases where the UI modules have permission sets with permissions from other backend modules, which could be defined in other applications.
Cons
Implementation for option 4
To avoid disappointing users when they see a capability set in the system that doesn't actually work (due to missing capabilities and resources), we need to hide the dummy capability sets from them. Additionally, even if we have some partially created capabilities required for the capability set, I suggest not displaying them to the end user. This can prevent confusion and simplify the implementation.
Currently, each time we create a new CapabilitySet, we always create it from scratch and never update it. We resolve the capability ID by its name, and if we can't find it, we exclude it from the result and log a warning.
private Optional<UUID> getCapabilityId(Map<String, UUID> existingCapabilityIdsMap, String capabilityName) {
var value = existingCapabilityIdsMap.get(capabilityName);
if (value == null) {
log.warn("Capability id is not found by capability name: {}", capabilityName);
return Optional.empty();
}
return Optional.of(value);
}So, instead of ignoring this capability set, we will create it regardless of whether it partially includes some capabilities or lacks them entirely. However, all missing capabilities need to be recorded in the dummy capability ID mapping table so that we can resolve them in the future once they are created.