SPIKE: MODKBEKBJ-504 User patron groups should be in sync with users app

Owned by Viacheslav Kolesnyk
Last updated: Feb 10, 2022
3 min read

MODKBEKBJ-504 - Getting issue details... STATUS

The main goal of this spike is to investigate how can we display actual user-related information in assigned-users list for kb-credentials.

Current problem:

User data is saved in mod-kb-ebsco  when user is assigned and then never updated so if data is modified in mod-users  then data in mod-kb-ebsco  becomes not relevant.

Current "assigned users" interactions

Possible solutions:



Pub-sub between mod-users and mod-kb-ebsco-javaBulk api for users in mod-users
Query data every time it's neededimplement scheduler to periodically update assigned users data
Advantages

Most preferable way for data consistency achievement.

Good performance for UX.

No need to store duplicate data and worry for data consistency.

Ensures data consistency.

Good performance for UX.

DisadvantagesWill cause a lot of "dummy" network traffic and unnecessary component load because kb-ebsco needs info only about certain users not all.Worst user-experience cause we need query data from multiple sources to display assigned users info so this will cause delays for data displaying.

Wasted processor time in most cases and delays in data consistency depending on scheduler rate.

Also unnecessary api calls in cases data is already consistent.

Potentially can cause big performance issues as database grows.

Developers effort to implement

Almost no changes to current code.

Add producer on mod-users on data changes and consumer for mod-kb-ebsco  to updated data based on notifications.

Rework database structure in mod-kb-ebsco (remove user-related info) to store only kb-id to user-id relations and update user assignment flow.

Implement bulk api in mod-users.

Add bulk api call to mod-kb-ebsco user assignment flow.

Implement bulk api in mod-users.

Add bulk api call to mod-kb-ebsco scheduler or implement api and let okapi run it periodically to update data.

Conclusion:

It was decided to remove user data from mod-kb-ebsco and query user-related info every time it is needed. Bulk api is not needed because users can be queried using cql.

To be implemented:

NoteWork to be doneModuleStory
Do anytime

Remove call to "/groups" api (i suppose it's even not used now)

Note: actually this is not a part of this spike, just wonder whether this api call is dummy. If so - it should be removed, but spike can be completed without this.

front-end/ui-eholdings

UIEH-1236 - Getting issue details... STATUS

Do first

Rework "GET /kb-credentials/{kb-credentials-id}/users" api:

  • get assigned users from db (only user ids by kb_credentials_id)
  • query users info from `mod-users` for assigned users using "/users" api and cql (Check the max possible amount of users we can query this way and implement batches so if for example we have 200 assigned users in db and the limit is 50 then we should execute 4 queries with 50 users each and compose results then)
  • query groups info using "/groups" api of  `mod-users`
  • aggregate received info and pass as response
back-end/mod-kb-ebsco

MODKBEKBJ-621 - Getting issue details... STATUS

Do together

Update "POST /eholdings/kb-credentials/{kb-credentials-id}/users":

  • remove "firstName", "lastName", "patronGroup", "userName" from api
  • update repository interaction (save only kb_id to user_id relation)
back-end/mod-kb-ebsco

MODKBEKBJ-622 - Getting issue details... STATUS

Update call to "POST /eholdings/kb-credentials/{kb-credentials-id}/users":

  • remove "firstName", "lastName", "patronGroup", "userName" from request body
  • also do not depend on this fields in response
front-end/ui-eholdings

UIEH-1237 - Getting issue details... STATUS

Do last

Schema updates:

  • remove `kb_users` table from db
  • remove `assigned_users_view`
  • update `assigned_users` constraint(user id is a foreign key now, but users table will be removed)
  • update `access_types` (remove view, constraints)

Code updates:

  • remove unused repository
  • update repository for new schema
  • remove other unused code related to user data
  • rework 'access-types' api to query user-related data from '/users' api of mod-users instead of database
back-end/mod-kb-ebsco

MODKBEKBJ-623 - Getting issue details... STATUS