UIU-2969: change user type confirmation modal

[alisher-epam]

Purpose

https://folio-org.atlassian.net/browse/UIU-2969

Approach

Screen.Recording.2024-02-08.at.15.57.41.mp4

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.

[Terala-Priyanka]

The Confirmation modal is being displayed on non-ECS environment too.
As per the ticket, the functionality applies to ECS enabled environment.
Please incorporate an ECS check.

[Terala-Priyanka]

@alisher-epam
looks like there is a new issue reported by Sonar. Please fix it.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue

Measures
0 Security Hotspots
95.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[Terala-Priyanka]

@alisher-epam
looks like the issue injected by your changes persists.
It was expected and agreed by you that it would be fixed.
Please fix it ASAP.

[NikitaSedyx]

@Terala-Priyanka render function already has high complexity, mb it's time for you to do a refactoring?

his condition is reasonable in render as it's part of OnChange (it could be improved, but still ok), when functions that are created inside render and contain conditions are definitely not expected (I have no idea who introduced them), so instead of fixing normal code just to fix, may be bad code should be refactored so sonar doesn't complain?

[Terala-Priyanka]

Just an FYI..
another PR #2636 with master as target, doesn't have this sonar complaint.
I did not dig much into the details

[NikitaSedyx]

just because someone could remove one of the conditions, but the point is the same, to ask to sustain quality - it should be initially in good state (I'm talking only for cases like this one, and not if quality is not so good we can do whatever we want)