Purpose/Overview:

Sharing an organization can be done from any tenant, whether it's a central or member tenant. In the scope of this story, we should implement a new endpoint that accepts an organization ID from any tenant and shares it with all available tenants using the mod-consortia-keycloak publish coordinator.

Flow of sharing/implementation:

• An optional dependency on mod-consortia-keycloak is added to the module descriptor.

• Mod-organization fetches the organization body by the organization ID that will be shared.

• Mod-organization should fetch all available tenants in the system to construct a publish coordinator request.

• There is no concept of shared and shadow organizations, all organization should be populated with single value type: “shared” and have the same organization IDs. An update performed in the central tenant of a shared organization should trigger an update across all tenants. Conversely, an update in a member tenant should be specific to that particular member tenant only.

• The logic to invoke the mod-consortia publish coordinator is invoked, which will create a shadow organization in all tenants.

• In response, a publish coordinator request ID is returned, fetched from the mod-consortia-keycloak response. In this case, the UI can track the progress of sharing the organization by invoking mod-consortia-keycloak if needed.

Note: when sharing organization, objects from the following accordions should have shared boolean property populated to true:

• Notes - separate story

• Contact information

• Contact people

• Privileged Donor information

• Interface

• Vendor terms

• Integration details - separate story

• Accounts

Question to discuss: Is it ok to use the context of user that makes sharing or using a system user more preferable especially if the organization can be shared from a member tenant by a user that can have a limited number of permissions?