Sharing settings with Consortium Members

This document will illustrate the design for sharing settings between members of a consortium.

Diagrams

Diagram for Share Setting functionality

PlantUML source code

@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

PlantUML source code

@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' MODCON-66 - Getting issue details... STATUS . 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"
}

{
    "pcId": "<UUID>"
}

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