Extend Dataverse metadatablocks API to retrieve metadata fields configured as required in the General Information page

[GPortas]

What this PR does / why we need it:

Changed api/dataverses/{id}/metadatablocks so that setting the query parameter onlyDisplayedOnCreate=true also returns metadata blocks with dataset field type input levels configured as required on the General Information page of the collection, in addition to the metadata blocks and their fields with the property displayOnCreate=true (which was the original behavior).

A new endpoint api/dataverses/{id}/inputLevels has been created for updating the dataset field type input levels of a collection via API.

Which issue(s) this PR closes:

• closes Extend the API to expose the dataset creation fields configured in the General Information page #10477

Special notes for your reviewer:

In api/dataverses/{id}/inputLevels, if one of the input levels corresponds to a dataset field type belonging to a metadata block that does not exist in the collection, the metadata block will be added to the collection. See: https://github.com/IQSS/dataverse/pull/10498/files#diff-fdb2c1fe72d58100303ed72894e5a2e26af2159463e7a2bf29ebca700dd64d45R36

I have created the UpdateDataverseInputLevelsCommand command that wraps the UpdateDataverseCommand command by adding the metadata block update logic, since UpdateDataverseCommand does not include metadata block updates for the new input levels.

Currently in develop the only UpdateDataverseCommand call that included input levels in the constructor (not null) is made in the DatasetPage and before calling the command the dataverse metadata blocks are updated, as can be seen here: https://github.com/IQSS/dataverse/blob/develop/src/main/java/edu/harvard/iq/dataverse/DataversePage.java#L673

A different approach to the new command could have been to modify UpdateDataverseCommand to update the dataverse metadata blocks within it. But I ultimately decided not to modify the command and instead create a new one, in order to reduce the risk of impacting existing behaviors.

The api/dataverses/{id}/inputLevels endpoint has been mainly created for the setup of integration tests that require prior updating of input levels. It is possible that this endpoint requires future extension to be consumed by the SPA.

Suggestions on how to test this:

Integration tests

The /metadatablocks endpoint tests have been updated and new tests have been created for the new /inputLevels endpoint.

Manual testing

1. Go to the General Information page of the collection you want to modify.
2. Set new metadata blocks and required fields.
3. Save the information
4. Call the api/dataverses/{id}/metadatablocks endpoint:

curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/dataverses/$ID/metadatablocks?returnDatasetFieldTypes=true&onlyDisplayedOnCreate=true"

5. Check that the metadata block that you added to the collection with only its required fields are returned, alongside the citation metadata block and its fields.

6. Repeat the same process but now updating the input levels via API:

Please note that this endpoint overwrites all the input levels of the collection page, so if you want to keep the existing ones, you will need to add them to the JSON request body.

curl -X PUT -H "X-Dataverse-key:$API_TOKEN" -H "Content-Type:application/json" "$SERVER_URL/api/dataverses/root/inputLevels" -d '[{"datasetFieldTypeName":"geographicCoverage", "required":true, "include":true}, {"datasetFieldTypeName":"country", "required":true, "include":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.579% (-0.01%) from 20.593%
when pulling 4bedbbd on 10477-dataset-fields-on-create-extension
into 3867cfe on develop.

[sekmiller]

Instead of adding this new command can you use the original UpdateDataverseCommand and pass in the inputlevel list?

[GPortas]

The UpdateDataverseInputLevelsCommand command wraps the UpdateDataverseCommand command by adding the metadata block update logic, which is not included in the UpdateDataverseCommand.

I explain this in more detail in the PR description section: Special notes for your reviewer

[sekmiller]

Also you need to set isMetadataBlockRoot to true so that the Dataverse knows that it not inheriting its MetadataBlocks from its parent - that is it has a different input level, etc.

[GPortas]

I just added that line and also check that the input list is not empty

[sekmiller]

There's one change that needs to be made with respect to updating isMetadataBlockRoot. Also suggesting that you might not need the new command.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:10477-dataset-fields-on-create-extension

ghcr.io/gdcc/configbaker:10477-dataset-fields-on-create-extension

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