UIU-2936: add user type for user info section #2551

alisher-epam · 2023-09-06T05:52:23Z

Purpose

UIU-2936 - add user type for User info section

Approach

TODOS and Open Questions

Learning

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

I've added appropriate record to the CHANGELOG.md
Does this PR meet or exceed the expected quality standards?
- Code coverage on new code is 80% or greater
- Duplications on new code is 3% or less
- There are no major code smells or security issues
Does this introduce breaking changes?
- If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
- There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

What other modules will these changes impact?
Do JIRAs exist to update the impacted modules?
- If not, please create them
- Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
- Do they have all they appropriate links to blocked/related issues?
Are the JIRAs under active development?
- If not, contact the project's PO and make sure they're aware of the urgency.
Do PRs exist for these changes?
- If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

zburke

I raised this issue already in #2546 but it was ignored there: All the supporting documentation refers to this property as "user type" and yet the variable is consistently named type. The code and the documentation must be consistent so either the code or the documentation must be changed. This will be easier now while the problem is still relatively small.

This may seem petty, but in a large system like FOLIO this kind of low-level friction becomes a real problem because it becomes impossible to predict what anything will be named. type? usertype? userType?

I will approve this PR when all code, translations, and documentation are consistent.

alisher-epam · 2023-09-06T14:32:57Z

@zburke I totally agree with you. I would use userType since it is descriptive rather than type. Only place type is required for the backend request. Does it make sense if I use an alias like so const USER_TYPE = 'type'?

zburke · 2023-09-06T17:49:46Z

@alisher-epam , IMNSHO, the backend folks should just fix their data structure. Short of that, I don't know what the cleanest/simplest option is. Maybe it's aliases as you suggest, or maybe it's just sucking it up and ignoring that all our labels will be User type and all our variables will be type.

I'll try to figure out a more useful venue to air my complaints. It's not your fault that you were given this conflicted API.

NikitaSedyx · 2023-09-11T16:55:42Z

@zburke just to confirm, does it mean that you don't block this PR even with type field usage? I agree that it's not the best name, but our team is not responsible for users modules (both BE and FE) and we can't easily replace it or in future - as an alternative we can create a ticket and volaris can decide how to proceed with it

zburke · 2023-09-11T18:33:28Z

@NikitaSedyx , correct, I am not blocking it. IMO this property should be called userType everywhere and this is a wart in the backend module. If it were up to me, I'd file a ticket for the backend module, wait for them to fix their bug, and then merge this PR. But I recognize that I'm not the PO and not the backend developer here.