Implement datasetType metadata block support (at global level)

cmbz commented 7 months ago

Overview

See https://github.com/IQSS/dataverse-pm/issues/307 and Proposal: Supporting Multiple Dataset Types in Dataverse for details

Proposed release not snippet (scope of work)

(See also notes where this snippet was iterated on.)

Metadata Blocks Can Be Associated with Dataset Types

Metadata blocks (e.g. "codemeta") can now be associated with dataset types (e.g. "software") using new superuser APIs.

This will have the following effects for the APIs used by the new Dataverse UI:

The list of fields shown when creating a dataset will include fields marked as "displayoncreate" (in the tsv/database) for metadata blocks (e.g. "codemeta") that are associated with the dataset type (e.g. "software") that is passed to the API.
The metadata blocks shown when editing a dataset will include metadata blocks (e.g. "codemeta") that are associated with the dataset type (e.g. "software") that is passed to the API.

For more information, see the guides and #10519.

Depends on

I liked the suggestion from @qqmyers that a possible direction would be to create a series of superuser-only APIs that allows an installation to be configured to associate a dataset type with metadata fields. However, what should the JSON look like that will ultimately be used by the SPA? Should we hide this output behind the "admin" API for now and check in with the frontend team (when they are ready) to see if the JSON is agreeable? In short, there would be no value to the end user yet, but we could make progress on database tables and business logic.

@scolapasta suggested that a smaller group (than all of tech hours) could discuss this issue further and unblock it. Meanwhile, perhaps the size should be removed and it should go back into "need sizing" for this discussion to happen (heads up to @cmbz).

cmbz commented 2 months ago

2024/09/25:

Possible option for SPA Q4 work. @GPortas will add as task to SPA Q4 proposal for evaluation.
@qqmyers @scolapasta @pdurbin and @cmbz will meet (coord via Slack) to follow up

cmbz commented 1 month ago

2024/09/30: See discussion and decisions here

pdurbin commented 1 month ago

Notes from our discussion (thanks, all).

In the issue description I'll copy the important bits and might try to future clarify things.

Updated: Sep 30, 2024 datasetType Discussion 2024/09/30

Attendees: Ceilyn Boyd Gustavo Durand Philip Durbin Jim Myers

Notes

https://github.com/IQSS/dataverse/issues/10519
The API-only option for configuration will meet GREI needs for Year 3, along with the Java/back-end changes to show the configured blocks when creating/editing a dataset. We will address the UI in Year 4 when the SPA beta is completed.
The current UI / SPA should already be leveraging this code in the way they get the metadata blocks, or should only require small tweaks.
A similar plan should work for configuring licenses for dataset types. Implement list of allowed datasetType licenses (at global level) · Issue #10520 · IQSS/dataverse (github.com)
Templates are out of scope and not expected to change
Tasks
- Create a series of superuser-only APIs that allows an installation to be configured to associate a dataset type with metadata blocks (fields in the future) at the global/installation level
- Modify underlying code to get fields that's used by JSF and API
- Modify the API the SPA uses to get the fields, allow type=software to be passed
- Change displayOnCreate to true for CodeMeta fields
Test case 1
- don't enable CodeMeta for a collection
- create dataset with type=software and ensure that CodeMeta fields show up
Ask SPA team to add a query parameter for type=software?

Action items *

IQSS / dataverse