UIREQ-1201: Update permission after mod-patron-blocks permission changes

[Dmitriy-Litvinenko]

Purpose

Update permission after mod-patron-blocks permission changes

Refs

https://issues.folio.org/browse/UIREQ-1201

[github-actions]

Jest Unit Test Statistics

       1 files  ±0       62 suites  ±0   1m 38s ⏱️ -7s
   797 tests ±0     797 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
1 106 runs  ±0  1 106 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 9512413. ± Comparison against base commit 1cd124f.

♻️ This comment has been updated with latest results.

[zburke]

Was there an accompanying change to the automated-patron-blocks interface version (or some other interface)? If there wasn't, there should have been 😬 and since you're dropping support for the old permission by removing automated-patrong-blocks.collection.get, that should be mentioned as a breaking change in the CHANGELOG. Alternatively, leave both permissions in place and update the interface dependency.

In NPM-land, leading zeros in a version string cause the minor version to behave like a major from the point of view of semver constraints, e.g. ^6.1.0 will give you >= 6.1.0, < 7.0.0, but ^0.6.1 will give you >= 0.6.1, < 0.7.0. I don't know how we handle this with respect to okapi interface versions, but it feels to me like this should have been accompanied by a change like

      "automated-patron-blocks": "0.1 0.2",

Oooof. There's a lot that's going on with this PR that is outside your control. Given that, and all you can do is react to the eco system you're living in, I will approve this. But I think you should consider leaving both permissions in place in order to maintain backwards compatibilty, even though the interface version didn't change the way it should have.

[Dmitriy-Litvinenko]

Was there an accompanying change to the automated-patron-blocks interface version (or some other interface)? If there wasn't, there should have been 😬 and since you're dropping support for the old permission by removing automated-patrong-blocks.collection.get, that should be mentioned as a breaking change in the CHANGELOG. Alternatively, leave both permissions in place and update the interface dependency.

In NPM-land, leading zeros in a version string cause the minor version to behave like a major from the point of view of semver constraints, e.g. ^6.1.0 will give you >= 6.1.0, < 7.0.0, but ^0.6.1 will give you >= 0.6.1, < 0.7.0. I don't know how we handle this with respect to okapi interface versions, but it feels to me like this should have been accompanied by a change like

      "automated-patron-blocks": "0.1 0.2",

Oooof. There's a lot that's going on with this PR that is outside your control. Given that, and all you can do is react to the eco system you're living in, I will approve this. But I think you should consider leaving both permissions in place in order to maintain backwards compatibilty, even though the interface version didn't change the way it should have.

@zburke Hello "Was there an accompanying change to the automated-patron-blocks interface version (or some other interface)?" no

Was there an accompanying change to the automated-patron-blocks interface version (or some other interface)? If there wasn't, there should have been 😬 and since you're dropping support for the old permission by removing automated-patrong-blocks.collection.get, that should be mentioned as a breaking change in the CHANGELOG. Alternatively, leave both permissions in place and update the interface dependency.

In NPM-land, leading zeros in a version string cause the minor version to behave like a major from the point of view of semver constraints, e.g. ^6.1.0 will give you >= 6.1.0, < 7.0.0, but ^0.6.1 will give you >= 0.6.1, < 0.7.0. I don't know how we handle this with respect to okapi interface versions, but it feels to me like this should have been accompanied by a change like

      "automated-patron-blocks": "0.1 0.2",

Oooof. There's a lot that's going on with this PR that is outside your control. Given that, and all you can do is react to the eco system you're living in, I will approve this. But I think you should consider leaving both permissions in place in order to maintain backwards compatibilty, even though the interface version didn't change the way it should have.

Hello @zburke

1. "Was there an accompanying change to the automated-patron-blocks interface version (or some other interface)?" no
2. "automated-patron-blocks.collection.get" added back

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud