-
Notifications
You must be signed in to change notification settings - Fork 541
Metadata fields can be "display on create" per collection #11312
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
Changes from all commits
5b37919
9518acd
404eb0b
97b454d
3c4e5cc
190f604
15fc52c
df39fb4
944911b
1db344b
848e391
973be9d
fe5abdb
21ba2c2
f0f91ef
ad3e92e
41bae39
080cf46
b9c6aa4
5c16c80
c1f402b
5e16582
67bbd37
56cfa92
f804fa3
e31db3d
4085c14
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| New feature: Collection administrators can now configure which metadata fields appear during dataset creation through the `displayOnCreate` property, even when fields are not required. This provides greater control over metadata visibility and can help improve metadata completeness. | ||
|
|
||
| - The feature is currently available through the API endpoint `/api/dataverses/{alias}/inputLevels` | ||
| - UI implementation will be available in a future release [#11221](https://github.com/IQSS/dataverse/issues/11221) | ||
|
|
||
| For more information, see the [API Guide](https://guides.dataverse.org/en/latest/api/native-api.html#update-collection-input-levels) and issues [#10476](https://github.com/IQSS/dataverse/issues/10476) and [#11224](https://github.com/IQSS/dataverse/pull/11224). |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -26,6 +26,9 @@ | |
| }, | ||
| "typeName": { | ||
| "type": "string" | ||
| }, | ||
| "displayOnCreate": { | ||
| "type": "boolean" | ||
| } | ||
| } | ||
| } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1116,20 +1116,27 @@ This endpoint expects a JSON with the following format:: | |
| { | ||
| "datasetFieldTypeName": "datasetFieldTypeName1", | ||
| "required": true, | ||
| "include": true | ||
| "include": true, | ||
| "displayOnCreate": null | ||
| }, | ||
| { | ||
| "datasetFieldTypeName": "datasetFieldTypeName2", | ||
| "required": true, | ||
| "include": true | ||
| "include": true, | ||
| "displayOnCreate": true | ||
| } | ||
| ] | ||
|
|
||
| .. note:: | ||
| Required fields will always be displayed regardless of their displayOnCreate setting, as this is necessary for dataset creation. | ||
| When displayOnCreate is null, the field's default display behavior is used. | ||
|
|
||
| Parameters: | ||
|
|
||
| - ``datasetFieldTypeName``: Name of the metadata field | ||
| - ``required``: Whether the field is required (boolean) | ||
| - ``include``: Whether the field is included (boolean) | ||
| - ``displayOnCreate`` (optional): Whether the field is displayed during dataset creation, even when not required (boolean) | ||
|
|
||
| .. code-block:: bash | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. by the way - the "fully expanded" example down below here has bad data - "required": true, "included": false |
||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -941,6 +941,12 @@ private Predicate buildFieldPresentInDataversePredicate(Dataverse dataverse, boo | |
| criteriaBuilder.isTrue(datasetFieldTypeInputLevelJoin.get("required")) | ||
| ); | ||
|
|
||
| // Predicate for displayOnCreate in input level | ||
| Predicate displayOnCreateInputLevelPredicate = criteriaBuilder.and( | ||
| criteriaBuilder.equal(datasetFieldTypeRoot, datasetFieldTypeInputLevelJoin.get("datasetFieldType")), | ||
| criteriaBuilder.isTrue(datasetFieldTypeInputLevelJoin.get("displayOnCreate")) | ||
| ); | ||
|
|
||
| // Create a subquery to check for the absence of a specific DataverseFieldTypeInputLevel. | ||
| Subquery<Long> subquery = criteriaQuery.subquery(Long.class); | ||
| Root<DataverseFieldTypeInputLevel> subqueryRoot = subquery.from(DataverseFieldTypeInputLevel.class); | ||
|
|
@@ -963,10 +969,19 @@ private Predicate buildFieldPresentInDataversePredicate(Dataverse dataverse, boo | |
| // Otherwise, use an always-true predicate (conjunction). | ||
| Predicate displayedOnCreatePredicate = onlyDisplayedOnCreate | ||
| ? criteriaBuilder.or( | ||
| criteriaBuilder.or( | ||
| // 1. Field marked as displayOnCreate in input level | ||
| displayOnCreateInputLevelPredicate, | ||
|
|
||
| // 2. Field without input level that is marked as displayOnCreate or required | ||
| criteriaBuilder.and( | ||
| hasNoInputLevelPredicate, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Related to making displayOnCrate nullable in the input level as noted below. If that is what's needed, then here: |
||
| criteriaBuilder.or( | ||
| criteriaBuilder.isTrue(datasetFieldTypeRoot.get("displayOnCreate")), | ||
| fieldRequiredInTheInstallation | ||
| ) | ||
| ), | ||
|
|
||
| // 3. Field required by input level | ||
| requiredAsInputLevelPredicate | ||
| ) | ||
| : criteriaBuilder.conjunction(); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the code currently allows this to be optional - line 806 in Dataverses sets it to false by default. I've tried to handle this in #11330, which should be ~ up to date with this PR, but still checking to see if I've broken tests. (I also added a test updating an inputLevel with no displayOnCreate value in that PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the doc can we just say that it default to false if omitted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm the dummy who wrote the migration script and didn't default the column to false. Should I add another update? Are we ready for more flyway migration errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be a backward incompatibility - if you don't include displayOnCreate you will override any true on the datasetfieldtype itself. If that's OK, then yes a doc change could address it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. didn't think of that.
\
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better if it's omitted that the value would come from the table for that datasetFieldType?