...
| Warning | ||
|---|---|---|
| ||
Module folio_consortia-settings should be enabled only in consortium central tenant |
Configure tenants
- Reference data & sample data should NOT be created on both central and institutional tenants
...
- .
| Warning |
|---|
Existing settings in a tenant cannot be shared via Consortium Manager. Settings have to be created via Consortium Manager to be shareable. |
- Reset password link, SMTP for sending emails should be configured on all tenants. Separate admin users in each tenant can be created to apply all this configuration.
...
Create admin user in the central tenant
...
The query used to fetch existing users, as used by 'mod-consortia,' is as follows: (cql.allRecords=1 NOT type="patron" NOT type="dcb" NOT type="shadow"). With this query, all users without a populated 'type' field or with a 'type' that does not equal 'patron' or 'dcb' will be migrated.
One important point to consider is that if, for example, 1.5 million patron users were created without populating the 'type' field as 'patron' when ECS was not enabled, all 1.5 million users will be migrated. This behavior is not desired because the validation of the 'type' as a required field is only enabled when ECS mode is enabled, and ECS should skip processing these users in the pipeline.
After enabling ECS mode
If we have a choice, it's preferable to enable ECS mode for the tenant and then begin creating/migrating users. These users will be processed by 'mod-consortia' via Kafka domain events sent by 'mod-users.'
In this scenario, users cannot be created without populating the 'type' field because validation is enabled in ECS mode. For some customers, we may have more than 1.5 million patron users and only a couple of thousand staff users. In this case, we can ensure that 'mod-consortia' will process only these thousands of staff users and exclude the millions of patrons.
In conclusion, it's better to migrate existing users after enabling ECS mode for the tenant.
Do we need to adjust our existing admin users to populate type='staff'
Let's begin with system users. All repositories have been updated to create new system users with the type 'system,' and a migration script has been written in 'mod-users' to add 'type='system'' for all existing system users.
So, for system users, no further actions are required.
For admin users, it's advisable but not mandatory. We recommend adding 'type='staff'' to avoid confusion regarding users that existed without a populated 'type' field in ECS mode, where this type field is required.
Additionally, some new features, such as filtering by user type in the Users App, will not consider users without a 'type' value.
However, even if 'type' is not populated for admin users, 'mod-consortia' will still select such users and process them through the ECS pipeline during the 'migrate existing users' process when adding the tenant to the consortium. This process includes users without a 'type' populated.
In conclusion, no action is needed for 'system' users, but for common admin users, it's advisable to add 'type='staff''.
BE Modules modified for supporting consortia functionality
Thunderjet team
...
Changes for config values
In consortium mode we have only 1 UI available for a central tenant, so properties that are stored in mod-configuration like FOLIO_HOST should be pointed to this single host for every tenant.
BE Modules modified for supporting consortia functionality
Thunderjet team
| № | Module | Changes made | Hosting changes | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | mod-consortia |
| Make sure that password for consortia system user populated via this env variable: SYSTEM_USER_PASSWORD, OKAPI_URL also should be populated. The full list of env variables is presented in the Readme: https://github.com/folio-org/mod-consortia#environment-variables | ||||||||
| 2 | mod-users |
| - | ||||||||
| 3 | mod-users-bl |
| - | ||||||||
| 4 | mod-login |
| - | ||||||||
| 5 | mod-authtoken |
| System param(declared in JAVA_OPTS) should be added: -Dallow.cross.tenant.requests=true
|
...
| № | Module | Changes made | Hosting changes | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | mod-search |
| Tenant paramenter centralTenantId should be added(during tenant enabling)
| ||||||||
| 2 | mod-entities-links |
| - |
...
| № | Issue description | Related tickets | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Simaultainious adding tenants to consortia can cause concurrent issues |
|
...