SN: Can we use System user for sharing settings, is it ok we system user affiliated

with for example 2 tenants, but can save shared records to 60 tenants?

OK: It should be product decision, use user identity or system user identity

DB: Share button requires separate new permission, even if admin affiliated only in 2 tenants, but with this permission shared settings should be created in all 65 tenants

SN: Is it acceptable to store phone numbers and email in user_tenant central schema?

SN: We already storing an unencrypted users data in member tenants, so I think nothing changes if we store them in central tenant now as well

RA: We are okay to keep the same approach, but basically need to ask in Security team, has action item to contact security team

OK: We are okay, if someone says that it is a concern - we can revisit, we are trying to maintain the same standard that Folio has. Consortium is the single entity.

ANWER: use an already existing standard approach without encryption, hashing etc. Roman had conversation with other architects and we have decision now to keep existing initial approach without introducing encryption and adding tenant dropdown

SN: We need to create shared user and affiliation or only shared user in central tenant, 

in case if we need affiliation - we also need to modify processing of USER_DELETED

event to delete affiliation from central tenant(shadow user already deleting in this case)

OK: We should create shadow user and affiliation in central tenant

ANSWER: We will create both shadow user and affiliation in central tenant during USER_CREATED and so will delete both shadow user

and affiliation during processing USER_DELETED

SN: For me it's better to login such users in central tenant instead of displaying Bad Credentials

OK: We should not allow users to login at all, because we have feature to enforce uniqueness

ANSWER: Khamid checked that it is not possible to login to central tenant using shadow user and we have error code username.incorrect in this case,

so decided to throw bad_credentials error code for multiple matching users

SN: If Poppy will be release and mod-consortia should be enabled, newly created users can be 

inserted un user_tenant table in mod-users without email, phone number and so we need to 

write some migration script in Q, to fetch all tenants to populate required data.

As solution we can mention in release notes that mod-consortia should be disabled for Poppy?

MS: Nobody will use consortia in Poppy release, let's talk to devops on Consortia hosting meeting to not enable this module in Poppy

OK: mod-consortia should be disabled by default, how will we deal with optional modules, don't enable them? We should not enable module

ANSWER: mod-consortia should be disabled, but even it enabled - it will not save any data, so we are safe here

How to understand is settings record was shared or not

If tenant was adding into existed consortium, should it contain all existed shared settings, instances, anything?

OL: For instance it is pretty instances, because instances live in central tenants. For settings - it should no

be handled by the system, it should be handled by particular tenant library, go to settings manager and copy

necessary settings to this member tenant as an option. This question is not for Q release

What is about reference data, for example for inventory, they should be shared automatically?

If yes , it should be shared after addding all tenants to consortium during setup phase? Or #2 should be used?

OL: Need to confirm with Dennis regarding reference data, we don't need to share all reference data, 

We have some data that should not be shared.

We need to know if we need to support editing of shared data, because if answer would be yes - so we could not use standardized mechanism for reference data and should use consortium manager for synchronization

DB: It is not super high priority for Q release

Do we need to support some transaction mechanism to save shared settings?

For example, admin has access to 3 member and 1 central tenant and admin wants 

to share 'Setting A' to tenant X where admin not presented,but that tenant already

contained 'Setting A' , so request to Tenant X would fail, do we need to revert changes in other 3 tenants?

DB: UI should check if any of the tenant already has this settings

SN: We can initiate new PC request to search by name to check if setting presented in all tenants or not, if it presented in some of tenant - we should throw an validation error 

We need to modify each dto schema to add new column source, if record was shared - we need to set up value as Consortium.

In local tenants we should prevent editing or deleting settings with source equals Consortium