mod-users-bl
- Tulkin Oltiboev
Overview
The module mod-users-bl includes common changes (see page) and additional critical update for Eureka compatibility. Key differences focus on:
Removal of
mod-users-blInstallationUser Role Reversal
Header and Permission Removal
OPTIONSMethod Status Code ChangeDynamic User ID Management
Removal of mod-users-bl Installation
The explicit installation of mod-users-bl has been removed. In the Eureka environment, we are using already created applications. See here about applications.
Before
...
# /bl-users/login requires a token to be created.
# In reality mod-login should depend on mod-authtoken.. But for bootstrap reasons, it doesn't (only an optional dependency). https://issues.folio.org/browse/MODLOGIN-155
# We can't add mod-users-bl here. The reason is that mod-users-bl has mod-authtoken as a dependency
# See note below about when mod-users-bl needs to be enabled. You can't do it here.
* table adminAdditionalPermissions
| name |
| 'users.all' |
| 'perms.users.get' |
| 'perms.users.item.put' |
| 'perms.users.assign.immutable' |
| 'owners.item.post' |
| 'accounts.item.post' |
# We are not able to add the mod-users-bl user permissions here(module should be enable before adding permissions). Instead we define our own table in configurePermissions.feature file
# and create those permissions there.
* table userPermissions
| name |
Scenario: create tenant and users for testing
Given call read('classpath:common/setup-users.feature'){ modules: '#(modulesArray)'}
# It would seem that mod-users-bl cannot be enabled before mod-authtoken, otherwise permissions problems will happen.
# mod-authtoken is enabled as the last step of setup-users.feature.
Scenario: install mod-users-bl
Given call read('classpath:common/tenant.feature@install') { modules: [{name: 'mod-users-bl'}], tenant: '#(testTenant)'}After
Background:
* url baseUrl
* table modules
| name |
| 'mod-permissions' |
| 'mod-configuration' |
| 'mod-users' |
| 'mod-login' |
| 'mod-feesfines' |
| 'mod-inventory' |
* table userPermissions
| name |
| 'users.item.post' |
| 'owners.item.post' |
| 'accounts.item.post' |
| 'proxiesfor.item.post' |
| 'usergroups.item.post' |
| 'users-bl.item.get' |
| 'users-bl.users-by-username.item.get' |
| 'users-bl.transactions.get' |
| 'users-bl.transactions-by-username.get' |
| 'users-bl.item.delete' |
Scenario: create tenant and users for testing
Given call read('classpath:common/eureka/setup-users.feature')
* eval java.lang.System.setProperty('mod-users-bl-testUserId', karate.get('userId'))
Scenario: create admin user for testing purposes
* def tempUser = testUser
* def testUser = { tenant: "#(testTenant)", name: '#(testAdmin.name)', password: '#(testAdmin.password)' }
Given call read('classpath:common/eureka/setup-users.feature@getAuthorizationToken')
Given call read('classpath:common/eureka/setup-users.feature@createTestUser')
Given call read('classpath:common/eureka/setup-users.feature@specifyUserCredentials')
* def testUser = tempUserUser Role Reversal
The primary test user (testUser) and the secondary test administrator (testAdmin) roles have been reversed. This changes the focus of the main feature (user-bl.feature).
Before:
After:
Note: test-admin will be created without any permissions. Why? Because we will use test-admin only to test functionality of existing userId and changed password for that user (in users-bl.feature)
Header and Permission Removal
The x-okapi-token header and permission list (from endpoint /bl-users/*) are no longer received in the Eureka environment. Consequently, the corresponding lines have been removed. See slack post.
Before:
After:
OPTIONS Method Status Code Change
The expected status code for the OPTIONS method has been changed from 204 to 200, reflecting the behavior of the Eureka environment.
Before:
After:
Dynamic User ID Management
Why This Change Was Necessary
Common functionality doesn’t create test users with static id anymore. That’s why we are saving id as variables and use it in the next test scenarios:
// users-bl-junit.feature
Scenario: create tenant and users for testing
Given call read('classpath:common/eureka/setup-users.feature')
* eval java.lang.System.setProperty('mod-users-bl-testUserId', karate.get('userId'))
// features/users-bl.feature
Background:
* call login testUser
* url baseUrl
* configure headers = { 'X-Okapi-Tenant': '#(testTenant)', 'x-okapi-tenant': '#(testTenant)', 'Authtoken-Refresh-Cache': 'true' , 'Accept': '*/*' ,'x-okapi-token': '#(okapitoken)' }
* def testUserId = java.lang.System.getProperty('mod-users-bl-testUserId')Why we are using Java properties?
Karate runs @BeforeAll (setup) and @Test (scenarios) in separate JVM processes. Global variables in one are not visible in the other. Java properties bridge this gap.