Consortia cases covered with Karate tests

Owned by Bekhzod Kurbonboev
Last updated: Jun 19, 2023
5 min read

Setup tenants

We define two tenants called 'centralTenant' and 'universityTenant' with 'consortiaAdmin' and 'universityUser1' users respectively. Then set up each tenant in 6 steps:

  1. POST required tenant to okapi
  2. Enable ['mod-login', 'mod-permissions', 'mod-configuration'] modules to be able to set up admin users. Notice that ['mod-users'] will also be enabled automatically.
  3. Create necessary user with credentials, and then add existing permissions of enabled modules to the user.
  4. Enable ['folio_users'] - when posting non-central tenants (isCentral = false) to consortium shadow admin user (of 'centralAdmin') will be created automatically with permissions ['ui-users.editperms'] so we need this module enabled before posting non-central tenant. Note that ['mod-password-validator', 'mod-authtoken', 'mod-users-bl', 'mod-pubsub', 'mod-notes', 'mod-inventory-storage', 'mod-circulation-storage', 'mod-event-config', 'mod-template-engine', 'mod-calendar', 'mod-patron-blocks', 'mod-email', 'mod-sender', 'mod-notify', 'mod-feesfines', 'mod-circulation', 'mod-tags'] will also be enabled automatically.
  5. Enable ['mod-consortia'].
  6. Add ['consortia.all'] permission to both created users. 

Note. Predefined users has fields [id, username, password, tenant] so whenever we do login these fields will be populated automatically along with [okapitoken] (if login was successful) so if we do not want to switch between tenants explicitly we just need to pick right user to do required request and leave headers as follows:

Consortium API tests


Scenariosub-scenario(s)status code
1


Create, Read, Update a consortium for positive cases

Create a consortium

201

Get consortiums

200

Get consortium

200

Update consortium

200
2


Create, Read, Update a consortium for negative cases

Attempt to get non-existing consortium

404

Attempt to update consortium with non-equal id in payload

400

Attempt to update non-existing consortium

404

Attempt to create second consortium

409


Tenant API tests

Big picture

Scenarios in 'tenant.feature' file we cover GET, POST, and PUT operations with all possible status codes except 401, and 403, and DELETE for only 404. And after each successful POST operation we also verify that:

  • For both type ('isCentral' = true and 'isCentral' = false) of tenants: 'consortia_configuration' table in '<tenant>_mod_consortia' has record for 'central' ('isCentral' = true) tenant;
  • For tenants 'isCentral' = false: 'user_tenant' table in '<tenant>_mod_users' has record for 'dummy_user'.

Scenariosub-scenariosstatus code
1






@Negative

Attempt to POST a tenant to the consortium






Attempt to create a tenant for consortia without 'adminUserId' query param ('isCentral' = false)

400

Attempt to create a tenant for consortia before 'central' tenant has been created

404

Attempt to create a tenant for non-existing consortium

404

Attempt to create a tenant without an 'id'

422

Attempt to create a tenant without a 'code'

422

Attempt to create a tenant without a 'name'

422

Attempt to create a tenant without 'isCentral'

422

Attempt to create a tenant with a

'name' that has length more than 150 characters and a 'code' with more than 3 characters		---
2



@Positive

Do POST a tenant, GET list of tenant(s) ('isCentral' = true)




Get tenants of the consortium (before posting any tenant)

200

Post a tenant with 'isCentral' = true ('centralTenant')

201

Get tenants of the consortium (after posting 'centralTenant')

200

Verify that 'consortia_configuration' in 'centralTenant' has record for 'central'('isCentral' = true) tenant

200
3



@Negative

Attempt to POST a second tenant with existing 'isCentral' = true, 'id', 'name', 'code'




Attempt to create a second central tenant ('isCentral' = true) 

409

Attempt to create a tenant with an existing 'id'

409

Attempt to create a tenant with an existing 'code'

409

Attempt to create a tenant with an existing 'name'

409
4





@Negative

Attempt to PUT existing tenant with invalid payload



Attempt to update a tenant with a different 'id'

400

Attempt to update the tenant for non-existing consortium

404

Attempt to update non-existing tenant

404

Attempt to update the tenant without an 'id'

422

Attempt to update the tenant without a 'code'

422

Attempt to update the tenant without a 'name'

422

Attempt to update the tenant without 'isCentral'

422

Attempt to update the tenant with a 'name' that has length more than 150 characters and a 'code' with more than 3 characters

---
5

@Positive

Do PUT the tenant

Update the tenants' 'code'

200

Update the tenants' 'name'

200
6

@Negative

Attempt to DELETE non-existing tenant, with non-existing consortiumId

Attempt to delete non-existing tenant in the consortium

404

Attempt to delete tenant by non-existing consortiumId

404
7


@Positive

Do POST a non-central tenant, GET list of tenant(s) ('isCentral' = false)

Create 'university' tenant

201

Get tenants by consortiumId - should get two tenants

200

Verify that 'consortia_configuration' in 'universityTenant' has record for 'central' tenant

200

Verify 'dummy_user' has been saved in 'user_tenant' table in 'university_mod_users'

200


User-Tenant-Associations

Big picture

Before posting tenants to the consortium tenants had following users:

  • 'consortiaAdmin' in 'centralTenant';
  • 'consortia-system-user' in 'centralTenant' (automatically created when 'mod-consortia' was enabled);
  • 'pubsub-user' in 'centralTenant' (we will not check this users' associations);
  • 'universityUser1' in 'universityTenant';
  • 'consortia-system-user' in 'universityTenant' (automatically created when 'mod-consortia' was enabled);
  • 'pubsub-user' in 'universityTenant' (we will not check this users' associations).

And mostly we need to investigate records in the following tables:

  • 'users' table in 'central_mod_users' - real users in all tenants should be saved here;
  • 'user_tenant' in 'central_mod_consortia' - primary and non-primary associations should be saved here;
  • 'user_tenant' in 'central_mod_users' - real users in all tenants should be saved here with 'tenant' information;
  • 'users' table in 'university_mod_users' - real users of 'universityTenant' and users who have non-primary association in 'universityTenant'  should be saved here.

test-idScenariosub-scenarios (action and verification)
1




con-1




Verify there are following records for  'consortiaAdmin':

1. 'consortiaAdmin' has been saved in 'users' table in 'central_mod_users'
2. 'consortiaAdmin' has been saved in 'user_tenant' table in 'central_mod_users'
3. primary affiliation for 'consortiaAdmin' has been created in 'user_tenant' table in 'central_mod_consortia'
4. shadow 'consortiaAdmin' has been saved in 'users' table in 'university_mod_users'
5. non-primary affiliation for shadow 'consortiaAdmin' has been created in 'user_tenant' table in 'central_mod_consortia'
6. verify shadow 'consortiaAdmin' has required permissions (in 'universityTenant')
2



con-2



Verify there are following records for 'consortia-system-user' of 'centralTenant':

1. 'consortia-system-user' has been saved in 'users' table in 'central_mod_users'
2. 'consortia-system-user' has been saved in 'user_tenant' table in 'central_mod_users'
3. primary affiliation for 'consortia-system-user' has been created in 'user_tenant' table in 'central_mod_consortia'
4. 'consortia-system-user' has required permissions
3




con-3




Verify there are following records for 'universityUser1':

1. 'universityUser1' has been saved in 'users' table in 'university_mod_users'
2. 'universityUser1' has been saved in 'user_tenant' table in 'central_mod_users'
3. primary affiliation for 'universityUser1' has been created in 'user_tenant' table in 'central_mod_consortia'
4. shadow 'universityUser1' has been saved in 'users' table in 'central_mod_users'
5. non-primary affiliation for shadow 'universityUser1' has been created in 'user_tenant' table in 'central_mod_consortia'
6. shadow 'universityUser1' has empty permissions (in 'centralTenant')
4




con-4



Verify there are following records for 'consortia-system-user' of 'universityTenant':

1. 'consortia-system-user' has been saved in 'users' table in 'university_mod_users'
2. 'consortia-system-user' has been saved in 'user_tenant' table in 'central_mod_users'
3. primary affiliation for 'consortia-system-user' has been created in 'user_tenant' table in 'central_mod_consortia'
4. 'consortia-system-user' has required permissions
5. shadow 'consortia-system-user' has been saved in 'users' table in 'central_mod_users'
6. non-primary affiliation for shadow 'consortia-system-user' has been created in 'user_tenant' table in 'central_mod_consortia'
7. shadow 'consortia-system-user' of 'universityTenant' has empty permissions (in 'centralTenant')
5



con-5


Add permissions of 'consortiaAdmin' to shadow 'consortiaAdmin'

#Note. There will be only one admin user, so need to add permissions of 'consortiaAdmin' to shadow 'consortiaAdmin'


6


con-6


Create a user called 'centralUser1' in 'centralTenant' and verify there are following records:

create user called 'centralUser1' in 'centralTenant'
1. 'centralUser1' has been saved in 'users' table in 'central_mod_users'
2. 'centralUser1' has been saved in 'user_tenant' table in 'central_mod_users'
3. primary affiliation for 'centralUser1' has been created in 'user_tenant' table in 'central_mod_consortia'
7




con-7




POST, DELETE, re-POST non-primary affiliation for 'centralUser1' verify there are following records:

#Note. We have 'centralUser1' in 'centralTenant' (circ-6)

POST non-primary affiliation for 'centralUser1' (for 'universityTenant')
1. shadow 'centralUser1' has been saved in 'users' table in 'university_mod_users'
2. shadow 'centralUser1' has empty permissions (in 'universityTenant')
DELETE non-primary affiliation for 'centralUser1' (for 'universityTenant')
3. shadow 'centralUser1' has been deactivated (in 'users' table in 'university_mod_users')
re-POST non-primary affiliation for 'centralUser1' (for 'universityTenant')
4. shadow 'centralUser1' has been reactivated (in 'users' table in 'university_mod_users')
8



con-8


Verify DELETE, re-POST of non-primary affiliation does not affect permissions of the user:
#Note. We have shadow 'centralUser1' in 'universityTenant' with 'active'=true, and empty permission

1. add non-empty permission to shadow 'centralUser1'
2. get updated permissions of shadow 'centralUser1'
DELETE non-primary affiliation for 'centralUser1' (for 'universityTenant')
re-POST non-primary affiliation for 'centralUser1' (for 'universityTenant')
3. verify that permissions of shadow 'centralUser1' after re-POST is not changes
9