This document will illustrate the design for sharing settings between members of a consortium.
Diagrams
Diagram for Share Setting functionality
@startuml
!pragma teoz true
!theme cerulean
autonumber
actor "user" as user
participant "mod-consortia" as mc
database "mod-consortia DB" as mc_db
participant "mod-consortia-publish-coordinator" as mc_pc
participant "mod-login" as ml
user -> mc: Initiate sharing setting action
note right
POST /consortia/<consortiumId>/sharing/settings
{
"settingId": "<UUID>",
"url": "string",
"payload": <<object>>
}
end note
activate mc
mc -> mc_db: Retrieve all setting tenant association from shared_setting table by setting id
mc -> mc_db: Retrieve all tenants list
loop tenants size count
alt #E8F3E1 tenant id is not exists in shared_setting table
mc -> mc: Add tenant to POST settings Publish Coordinator tenants lists
else #F3E1E2 tenant id is exists
mc -> mc: Add tenant to PUT settings Publish Coordinator tenants lists
end
end
mc -> mc: Set source as Consortium to all seetings(both for Create and Update)
mc -> ml: Login via consortia-system-user
ml --> mc: Return system user's token
mc -> mc_pc: Initiate PC request with POST HTTP method to create settings
mc_pc --> mc: Return Publish Coordinator id
mc -> mc_pc: Initiate PC request with PUT HTTP method to update settings
mc_pc --> mc: Return Publish Coordinator id
mc --> user: Return response with both PC ids
note right
Response payload:
{
"createSettingsPCId": "<UUID>",
"updateSettingsPCId": "<UUID>"
}
end note
user -> mc: Check if POST PC completed: /consortia/<UUID>/publications/<UUID>
user -> mc: Check if PUT PC completed: /consortia/<UUID>/publications/<UUID>
@enduml |
Diagram for Delete Shared Setting functionality
@startuml
!pragma teoz true
!theme cerulean
autonumber
actor "user" as user
participant "mod-consortia" as mc
database "mod-consortia DB" as mc_db
participant "mod-consortia-publish-coordinator" as mc_pc
participant "mod-login" as ml
user -> mc: Initiate sharing setting action
note right
DELETE /consortia/<consortiumId>/sharing/settings/<settingId>
{
"settingId": "<UUID>",
"url": "string"
}
end note
activate mc
mc -> mc_db: Retrieve all setting tenant association from shared_setting table by setting id
loop tenants where setting exists
mc -> mc: Add tenant to DELETE Publish Coordinator tenants list
end
mc -> mc_db: Delete from shared_setting by setting id
mc -> ml: Login via consortia-system-user
ml --> mc: Return system user's token
mc -> mc_pc: Initiate PC request with DELETE HTTP method to delete settings
mc_pc --> mc: Return Publish Coordinator id
mc --> user: Return response with PC id
note right
Response payload:
{
"pcId": "<UUID>"
}
end note
user -> mc: Check if DELETE PC completed: /consortia/<UUID>/publications/<UUID>
@enduml |
Key concepts
How to understand is setting shared
New field 'source' will be added to all settings with new allowed value 'Consortium' 
. It will be used as a sign that this is shared record and also we can rely on this property to prevent editing or deleting
settings with source = 'Consortium'
Usage of Publish Coordinator functionality
This endpoint will use Publish Coordinator functionality to initiate the sharing setting process and in response will return publish coordinator uuid.
This new endpoint will query the tenant table to fetch all available tenants and initiate a new Publish Coordinator request.
The invoker side will use standardized /consortia/<UUID>/publications/<UUID> endpoints to check if sharing action completed.
Understanding do we need to create or update shared setting
New table shared_setting will contain the setting uuid and tenant id. If setting uuid is missed in this table - it means we need to initiate POST action or PUT otherwise. It means 2 PC requests would be
initiated.
Storing settings and tenants associations in central tenant provides one more benefit, if new tenant will be added after some time, all existing Consortium settings can be migrated esially because we have now some centralized place where all Consortium shared settings are stored. |
User for initiate sharing action
System user will be used to initiate the sharing setting process, because shared setting should be applied to all tenants. It solves issue when currently logged in user is not affiliated in some tenant
Additional Development
Sharing Endpoints
| URL | Method | Request Body | Response Body | Comment |
|---|
| /consortia/<consortiumId>/sharing/settings | POST |
{
"settingId": "<UUID>",
"url": "string",
"payload": <<object>>
} |
|
{
"createSettingsPcId": "<UUID>",
"updateSettingsPcId": "<UUID>"
} |
| Start a sharing action for the setting. In response there is 2 ids of 2 different PC requests: for create and update setting in tenants |
| /consortia/<consortiumId>/sharing/settings/<settingId> | DELETE |
{
"settingId": "<UUID>",
"url": "string"
} |
| | Start a deleting shared setting process. In response there is id of related PC request |
DB table structure
New table shared_setting will be created and store setting and tenant associations in the central tenant with following structure:
| Field | Type | Comment |
|---|
| id(PK) | UUID | Unique identifier of table |
| setting_id(indexed) | UUID | Contains shared setting uuid |
| tenant_id | Text | Contains tenant where setting was shared |
Questions
- Will it be possible to edit the name of the shared setting or some other property from Consortium Manager? SN: (This design was created for positive answer) DB: Yes for sure
- Will it be possible to delete shared setting? SN: (This design was created for positive answer) DB: We should allow deleting, but for cases if delete was not succesful - we should convert from Consortium source to User source in member tenants
- If we allow to edit setting name with source = Consortium in Consortium manager, how we can prevent editing in member tenant in this case? DB: yes and tickets created MS: It will be UI validation
- Un-share vs Delete shared setting. DB: Unsare can be out of scope JR: Unshare is not supported