Fix metadata field type display condition in dataverses/{id}/metadatablocks API endpoint

[GPortas]

What this PR does / why we need it:

dataverses/{id}/metadatablocks API endpoint has been fixed, since the fields returned for each metadata block when returnDatasetTypes query parameter is set to true was not correct.

Which issue(s) this PR closes:

Closes #10637

Special notes for your reviewer:

The goal of the changes is for the endpoint to return the correct blocks and field types for both the create dataset form (onlyDisplayedOnCreate=true) and the edit dataset form (onlyDisplayedOnCreate=false).

The conditions on the input levels, which are configured when creating or editing the collection, were not working as expected.

Suggestions on how to test this:

New IT tests have been added, but for manual testing, follow these steps:

Create different collections with required or included fields (input levels) using the checkboxes in the metadata fields section.

Then, call the dataverses/{id}/metadatablocks API endpoint using returnDatasetFieldTypes=true, for each collection you created.

First, add onlyDisplayedOnCreate=true to return the fields that should be displayed in the create dataset form. This should match what you see on JSF:

curl -H "X-Dataverse-key:XXXXX" "http://localhost:8080/api/dataverses/{ID}/metadatablocks?returnDatasetFieldTypes=true&returnDatasetFieldTypes=true"

Then, add onlyDisplayedOnCreate=false, to return the fields you see in the edit dataset form. Again, this should match what you see on JSF:

curl -H "X-Dataverse-key:XXXXX" "http://localhost:8080/api/dataverses/{ID}/metadatablocks?returnDatasetFieldTypes=false&returnDatasetFieldTypes=true"

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

No

Is there a release notes update needed for this change?:

Yes, attached.

Additional documentation:

None

[coveralls]

coverage: 20.655% (-0.006%) from 20.661%
when pulling 9073328 on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.658% (-0.003%) from 20.661%
when pulling 9073328 on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.658% (-0.003%) from 20.661%
when pulling ab2128d on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.66% (-0.001%) from 20.661%
when pulling 1246d7c on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.662% (+0.001%) from 20.661%
when pulling 1606a12 on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[qqmyers]

Overall, this looks fine. I have a question as to whether one of the new methods is needed. Depending on the answer there, there could be changes or this could go ahead as is.

The IT test looks OK but a little hard to follow, so making sure manual QA includes the recommended comparison between the JSF UI and API output would be a good confirmation.

[coveralls]

coverage: 20.627% (-0.03%) from 20.661%
when pulling b1bed76 on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.627% (-0.03%) from 20.661%
when pulling b1bed76 on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.662% (+0.001%) from 20.661%
when pulling b1bed76 on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[coveralls]

coverage: 20.662% (+0.001%) from 20.661%
when pulling b8fe59c on 10637-metadatablocks-input-levels-extension
into 853965e on develop.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:10637-metadatablocks-input-levels-extension

ghcr.io/gdcc/configbaker:10637-metadatablocks-input-levels-extension

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.

[qqmyers]

Looks good. All comments addressed.