addDataverse API endpoint extension for input levels and facet list setup

[GPortas]

What this PR does / why we need it:

The addDataverse (/api/dataverses/{identifier}) API endpoint has been extended to allow adding metadata blocks, input levels and facet ids at creation time, as the Dataverse page in create mode does in JSF.

Which issue(s) this PR closes:

• Closes Extend create collection API endpoint to include facet list and input level list  #10633

Special notes for your reviewer:

I had to modify the CreateDataverseCommand to add the logic for adding metadata blocks, as well as other logic related to the Dataverse instance and its input levels and facets. I also had to reorder the code for persisting the dataverse collection with all the changes.

The logic I had to add to the command was previously handled in JSF from the Dataverse Page before calling the command, and without these modifications, calling the command from the API with input levels and/or facet ids resulted in an inconsistent state for the created Dataverse. The API was sending facetIds and inputLevels as null, since they were not supported in the endpoint request body, so these issues went unnoticed.

I have implemented the changes in such a way that they do not interfere with the current behavior of JSF, as the command is still consumed in the same way in JSF and I have not made any changes to the DataversePage.class. I have performed several manual tests with logging to ensure that there is no impact on the behavior of JSF, but due to the lack of test coverage in this area, I recommend an analysis of possible implications by the PR reviewer.

Suggestions on how to test this:

IT tests have been implemented, covering cases where metadata blocks, input levels, or facet IDs are set in the dataverse collection. However, I recommend performing manual tests by calling the endpoint and verifying the correct persistence of the dataverse, its metadata blocks, input levels, and facets.

Create JSON file following the new example provided in the docs: https://github.com/IQSS/dataverse/blob/e65eb9f947beec06ddbfc6f0bfb73f7ecaf60d28/doc/sphinx-guides/source/_static/api/dataverse-complete-optional-params.json

Call the endoint as described in the docs:

curl -H "X-Dataverse-key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -X POST "https://demo.dataverse.org/api/dataverses/root" --upload-file dataverse-complete-optional-params.json

Now you need to verify that all necessary information about the new dataverse collection, its metadata blocks, input levels, and facet IDs has been correctly persisted.

We can confirm that the information has been correctly persisted if, after entering the dataverse collection page, the input levels and facets sections have the fields set in the JSON.

Input levels:

Facet ids:

As an additional verification, we can check the persisted information in the related database tables.

• dataverse_metadatablock table
• dataversefieldtypeinputlevel table
• dataversefacettable

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

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

Additional documentation:
None

[coveralls]

coverage: 20.661%. remained the same
when pulling 3dd6355 on 10633-create-collection-api-ext
into 0f0c3b6 on develop.

[coveralls]

coverage: 20.659% (-0.002%) from 20.661%
when pulling 1cc48b7 on 10633-create-collection-api-ext
into 0f0c3b6 on develop.

[coveralls]

coverage: 20.659% (-0.002%) from 20.661%
when pulling 8c88d14 on 10633-create-collection-api-ext
into 0f0c3b6 on develop.

[coveralls]

coverage: 20.654% (-0.007%) from 20.661%
when pulling 7840a02 on 10633-create-collection-api-ext
into 0f0c3b6 on develop.

[coveralls]

coverage: 20.628% (-0.03%) from 20.661%
when pulling 1651f80 on 10633-create-collection-api-ext
into 0f0c3b6 on develop.

[coveralls]

coverage: 20.655% (-0.006%) from 20.661%
when pulling 1651f80 on 10633-create-collection-api-ext
into 0f0c3b6 on develop.

[coveralls]

coverage: 20.629% (-0.006%) from 20.635%
when pulling cb4d1ac on 10633-create-collection-api-ext
into 43ee260 on develop.

[coveralls]

coverage: 20.629% (-0.006%) from 20.635%
when pulling cb4d1ac on 10633-create-collection-api-ext
into 43ee260 on develop.

[coveralls]

coverage: 20.629% (-0.006%) from 20.635%
when pulling cb4d1ac on 10633-create-collection-api-ext
into 43ee260 on develop.

[coveralls]

coverage: 20.629% (+0.003%) from 20.626%
when pulling 27adc35 on 10633-create-collection-api-ext
into b42222f on develop.

[GPortas]

@sekmiller Requested changes addressed.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:10633-create-collection-api-ext

ghcr.io/gdcc/configbaker:10633-create-collection-api-ext

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

[sekmiller]

Looks Good! Thanks for the updates and welcome back

[landreev]

@GPortas Please note that Jenkins tests keep failing. It appears that the 3 failures from last week happened because the version was still 6.2 in the dataverse-parent pom.xml. But I synced the branch with develop earlier today, and the tests failed again. I can't tell why it failed this time right away.
https://jenkins.dataverse.org/job/IQSS-Dataverse-Develop-PR/view/change-requests/job/PR-10644/24/

[GPortas]

@landreev I am still looking for the causes.

The unit test action is also failing, the problem is on war file building. In particular, te issue happens when trying to download an artifact: 'Could not find artifact org.primefaces.themes:all-themes:jar:1.0.10.' You can see it more detailed in the action logs: https://github.com/IQSS/dataverse/actions/runs/10062830362/job/27861057069?pr=10644

This has happened since the develop merge you pushed, it had not happened before. I reran the action several times and encountered the same problem.

In Jenkins, it seems that the job also fails at the same point, when building the war file, take a look at this screenshot:

But war building and unit tests work on my localhost with no problems...

[landreev]

@GPortas yes, this is happening because of #10718 (missing dependency; in preexisting build environments it's still working because the jar file is cached under ~/.m2)

[landreev]

I'm ready to merge this, but will wait until tomorrow for the Primefaces dependency issue to be fixed; just to see automated tests pass.