UISAUTHCOM-48: fix cap set remains assigned after selecting and then deselecting it when creating an authorization role

[aidynoJ]

Refs UISAUTHCOM-48.

Approach: updated line code of useApplicationCapabilitySets accidentally got into the release. Revert the line back

Purpose

Approach

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.

[github-actions]

Jest Unit Test Results

  1 files  ±0   51 suites  ±0   1m 43s ⏱️ +6s
152 tests ±0  151 ✅ ±0  1 💤 ±0  0 ❌ ±0 
160 runs  ±0  159 ✅ ±0  1 💤 ±0  0 ❌ ±0 

Results for commit e6f0916. ± Comparison against base commit 20ae074.

[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 SonarQube Cloud

[zburke]

I'm trying to follow the history here. The work for UISAUTHCOM-43 was originally done in two PRs, #65 and #67. Those where cherry-picked together onto the b1.0 release branch in #68. This PR edits one of the changes from PR 65, presumably because it was built on top of something that had merged to master but after the b1.0 split. OK; that makes sense for what is happening in this PR.

But as for this PR's target:

1. I think it should be b1.0 so we can publish another patch (e.g. v1.0.3)
2. I don't understand why b1.1 was split from b1.0; I would expect a b1.1 branch to be split from master after additional feature work was committed on master.

@aidynoJ, can you clarify the intent here?

[aidynoJ]

I'm trying to follow the history here. The work for UISAUTHCOM-43 was originally done in two PRs, #65 and #67. Those where cherry-picked together onto the b1.0 release branch in #68. This PR edits one of the changes from PR 65, presumably because it was built on top of something that had merged to master but after the b1.0 split. OK; that makes sense for what is happening in this PR.

But as for this PR's target:

1. I think it should be b1.0 so we can publish another patch (e.g. v1.0.3)
2. I don't understand why b1.1 was split from b1.0; I would expect a b1.1 branch to be split from master after additional feature work was committed on master.

@aidynoJ, can you clarify the intent here?

Ah, I see what you mean, so instead of b1.1 I should create PR to b1.0 and from it create the tag 1.0.3 , right?

[zburke]

Replaced by #76