UIU-3105: hide permissionSets from settings/users navigation pane if roles interface is present

[aidynoJ]

Purpose

UIU-3105 - suppress Settings > Users > Permission sets when roles interface is present

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]

This works, but in Eureka, we don't have mod-permissions, so the permissions interface won't exist at all, right? If that's correct, lets implement like we did for fees and fines on line 133, leveraging the filter on SettingsPage to implement this in a less obtrusive/more generic way.

[aidynoJ]

This works, but in Eureka, we don't have mod-permissions, so the permissions interface won't exist at all, right? If that's correct, lets implement like we did for fees and fines on line 133, leveraging the filter on SettingsPage to implement this in a less obtrusive/more generic way.

Unfortunately, backend relies on permissions interface for migrations, and currently we might see this situation(picture below). As a result we will have interface "permissions" in eureka for now. Probably, later when backend will not use permissions interface we could use fees and fines way to handle it.

the changes I asked for are not practical

[zburke]

I hesitate to approve this because getSettingSections is just so out of place, and so specific to the perms route. True, it gets the job done, but without any context since there are no comments here and the route in question is not defined here.

I think a better approach may be to handle this directly in sections.js where we could use the same conditionals to evaluate whether to unshift this route onto the settingsGeneral list.

I also don't understand how the new tests evaluate the condition we are adding here. All the tests do is check whether the settings page renders, not whether the content it renders changes when the interface list changes.

[aidynoJ]

I hesitate to approve this because getSettingSections is just so out of place, and so specific to the perms route. True, it gets the job done, but without any context since there are no comments here and the route in question is not defined here.

I think a better approach may be to handle this directly in sections.js where we could use the same conditionals to evaluate whether to unshift this route onto the settingsGeneral list.

I also don't understand how the new tests evaluate the condition we are adding here. All the tests do is check whether the settings page renders, not whether the content it renders changes when the interface list changes.

I'll try to handle it differently.

[zburke]

Ooooh, this is very nice! What if we rename dependsOnNoneInterface to unlessInterface?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarCloud