MODLD-646: Update response schema of authority assignment check API

[pkjacob]

Earlier, POST /linked-data/authoritty-assignment-check API was returning a boolean (true/false) value.
As part of MODLD-646, the response structure of the API is changed as follows

{
   "validAssignment": false,
   "reason": "NOT_VALID_FOR_TARGET"
}

Purpose of this change is to update UI accordingly.

Should be merged along with folio-org/mod-linked-data#104

Closing this PR as this is replaced by #85.

[github-actions]

Jest Unit Test Results

0 tests  ±0   0 ✅ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit 95c1265. ± Comparison against base commit a8517d2.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[zburke]

Buncha things:

• Changing the shape of an API response in this way is a breaking change and hence should be accompanied by a new major version in the interface. Please update stripes.okapiInterfaces in packages.json with the new interface version, and increment this package's major version as well.
• Include a CHANGELOG.md entry describing this work
• Create a corresponding ticket in the Jira project for ui-linked-data in order to correctly assign a fix-version to this work.

[pkjacob]

Hi @zburke, Linked data is still not in production. We are going live first time in Sunflower. So, should we still update the version in okapiInterface? I think we need to increment versions only after we go live. right?

[zburke]

@pkjacob, leaving everything at v1 until the first "real" release is just fine 👌 . The other tasks remain though:

Add a stripes section to your package.json with an okapiInterfaces property that includes the interfaces and their versions. Without that, you cannot generate a proper module descriptor, which will be used to figure out which backend modules/versions will be necessary.

Create a UILD ticket in Jira for this work instead of repurposing the MODLD ticket. Using the corresponding project allows Jira and GitHub to stay in sync and properly assign the "fix version" field.

If the changes I'm requesting are out of step with the stage of development here then I don't want to hold up progress. As you move toward a production release, you must have a CHANGELOG, you must document the okapi interfaces and versions you rely on, you must correctly match PRs to Jira tickets. But I understand that these things do not all happen at once.

If you're ready to follow these guidelines now, great! If you're not, that's ok too, but maybe don't request reviews from @fe-tl-reviewers just yet. Ping us when you're ready and I'll be happy to nitpick all these little details :laugh:

[pkjacob]

Hi @zburke,

Thank you for the comments. Please see response below.

Add a stripes section to your package.json with an okapiInterfaces property that includes the interfaces and their versions. Without that, you cannot generate a proper module descriptor, which will be used to figure out which backend modules/versions will be necessary.

This application is not a real FOLIO module. This is a standalone application that Library of Congress (& other libraries) may run outside of their FOLIO installation. That is the reason why we no not have any stripes section in package.json file.

In order to run this application within a FOLIO platform, we need to wrap this application in a stripes module. We have another repository ui-ld-folio-wrapper for this purpose. If you look at the package.json of ui-ld-folio-wrapper, you can see the okapiInterfaces section.

Create a UILD ticket in Jira for this work instead of repurposing the MODLD ticket. Using the corresponding project allows Jira and GitHub to stay in sync and properly assign the "fix version" field.

Thank You. I created a new UI ticket UILD-497 and created a new PR: #85. I will close this PR now.