-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement datasetType metadata block support (at global level) #10519
Comments
As discussed at tech hours yesterday, I pulled this into FY25 Sprint 5 two weeks ago without realizing how poorly defined this issue is and without grasping that the proposal, as written, implies a lot of work on the JSF code, which we intend to dispose of. 🗑️ 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). |
2024/09/25:
|
2024/09/30: See discussion and decisions here |
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 Attendees: Ceilyn Boyd Gustavo Durand Philip Durbin Jim Myers Notes
Action items |
2025-01-22: Closing as complete: #10519. |
JsonPrinter was edited in #10764 and #11066 which were merged five and two weeks ago, respectively. This caused merge conflicts which should be resolved correctly now. In this commit, we are starting with JsonPrinter as of the most recent "develop" branch commit (7fdb21a) and adding in our DatasetType changes. PR #10764 resulted in the number of metadata fields being reduced from 80 to 35 and this commit make the same change in an assertion.
In Docker, we were testing with the Codemeta block. This made for a nice real-world story of creating a "software" dataset type and using it with the Codemeta block. The Codemeta block also has the advantage of having some fields that are set to displayOnCreate, which helped us make assertions that the code is working properly. It's the only non-citation block with fields set to displayOnCreate. However, Jenkins doesn't have the Codemeta block, meaning that tests are failing. Also, we aren't ready to promote the Codemeta block to be shipped with Dataverse because a new version is out: #10859 So, we are switching from Codemeta to the Astrophysics block. We create an "instrument" dataset type. Like all non-citation blocks (except for Codemeta), there are no fields that are set to displayOnCreate=true. Therefore, we added an API for this.
Reopening. This issue will be auto-closed when this PR is merged: |
Conflicts: src/test/java/edu/harvard/iq/dataverse/api/UtilIT.java
Overview
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:
For more information, see the guides and #10519.
Depends on
Implement a global setting and/or API for dataset types #10518See also
The text was updated successfully, but these errors were encountered: