Definition of the flows of global "settings" to local and how it can be overridden

[einari]

The IFRC needs to centralized be able to define settings that are for everyone. Settings are specifically defined in each bounded context, and some bounded contexts might not have settings.

There needs to be a "global" tenant - which represents the IFRC. A person with the right authority / role (claim) can then perform changes to settings. This might be fine grained authorization down to each bounded context, or higher. This remains to be defined.

The settings have a specific set of rules on how it should work:

• Any changes done from a centralized (global) perspective the first time - meaning the setting does not exist in the tenant (national society) should just apply the setting
• Any subsequent changes needs to accepted or rejected by the tenant (national society). Only a person with the right authorization level can see this and be able to accept or reject it.
• When accepted, the centralized / global owner needs to be able to see that a change has been accepted or rejected - to give context into things like the epidemiology time-graph thingy.
• In order for the tenant administrator to be able to see that a global change has occurred, we should formalize something like a system base data change inbox or similar. This inbox would then contain the changes and information about the change and possibly have an action associated with it. Some notifications are just notifications and don't need to have an action associated.

UI

The inbox concept should something that is globally cross cuttingly available some how. We should look at having a system that the different bounded contexts can provide a definition for the different types of events it is interested in having associated actions with. For inspirational, we could be looking at how Microsoft Teams is doing this for its messages - a simple structure with details on it and actions that can point back to an action in the form of a URL that will deal with the acceptance.

Sketch(WIP, please comment for UI specific questions): https://preview.uxpin.com/6e81bbc0eae0da3e78943f7681e4dcdf552edb3b#/pages/102223366 (click on the alarm bell :) )

Dolittle

From a underlying infrastructure perspective, Dolittle needs to support the concept of routing events. Routing needs to be done in a one to many relationship with regards to taking events from one tenant to many. This means producing copies of any event falling into the routing for each tenant for instance. This should be generalized in a way that means we can do routing in many different ways. Another way of routing would be back from a local to a global as well. This needs an internal round at Dolittle to figure out a good way do this. There could be a pattern for recognizing things that are implicit.

Provisioning

When a tenant (national society) is to be provisioned. Every bounded context need to be able to be part of the provisioning, providing default data from this global "tenant" - for instance, settings like health risks from Admin and default thresholds from Alerts.

[alexanderhoset]

Added a cleaner role description of the global "tenant" in the Provisioning Paragraph

[Ulriksen]

There is a need to report aggregate numbers from each tenant into the global tenant to get a global overview, and this should be handled in the analytics domain on a global level.

[tineml]

This issue can wait until we have an earlier version of the platform in place. I can follow up on this issue once relevant again.