Skip to content

DD-2075: Hidden fields of a dataset creation form remain visible AND setting a field to 'hidden' is not working #11992 #12017

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.

Sign up for GitHub

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

Open
aliassheikh wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

DD-2075: Hidden fields of a dataset creation form remain visible AND setting a field to 'hidden' is not working #11992 #12017

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1d68e41
DD-2075: Hidden fields of a dataset creation form remain visible AND …
aliassheikh Dec 3, 2025
fe42efb
Merge branch 'develop' into DD-2075-IQSS-11992
janvanmansum Dec 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/main/java/edu/harvard/iq/dataverse/DataversePage.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1348,7 +1348,7 @@ private void saveInputLevels(List<DataverseFieldTypeInputLevel> listDFTIL, Datas
existingLevel.setInclude(dsft.isInclude());
existingLevel.setRequired(dsft.isRequiredDV());
listDFTIL.add(existingLevel);
} else if (dsft.isInclude() || (dsft.getLocalDisplayOnCreate()!=null) || dsft.isRequiredDV()) {
} else if (!dsft.isInclude() || (dsft.getLocalDisplayOnCreate()!=null) || dsft.isRequiredDV()) {
Copy link
Member

@qqmyers qqmyers Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense for the given use case - trying to hide a field. TLDR: looks like a good fix.

I think I've convinced myself that we can't have the opposite case - a field that is hidden by metadatablock definition and needs to be turned on. If that was a possibility, we'd need something like a refactor to make include a nullable Boolean (like localDsiplayOnCreate). Further, it makes me wonder if we also would have a problem if a field were defined as required and someone wanted to override that. However, in that case it looks like we don't let people change required to false in the UI - the field shows as 'required by Dataverse' instead of having radio buttons. So - in both cases, it looks like there isn't currently a way to create the cases that would break the logic.

// Only create new input level if there is any specific configuration
listDFTIL.add(new DataverseFieldTypeInputLevel(
dsft,
Expand Down
2 changes: 1 addition & 1 deletion src/main/webapp/metadataFragment.xhtml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -244,7 +244,7 @@
<div class="panel-body">
<ui:repeat value="#{metadataBlockVal.value}" var="dsf" varStatus="curField">
<div class="form-group" role="group"
jsf:rendered="#{((editMode == 'METADATA' or dsf.datasetFieldType.shouldDisplayOnCreate() or !dsf.isEmpty() or dsf.required or dsf.hasRequiredChildren)) or (!datasetPage and dsf.include)}">
jsf:rendered="#{((editMode == 'METADATA' or dsf.datasetFieldType.shouldDisplayOnCreate() or !dsf.isEmpty() or dsf.required or dsf.hasRequiredChildren) and dsf.include) or (!datasetPage and dsf.include)}">
Copy link
Member

@qqmyers qqmyers Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tested but this seems odd - if dsf.isEmpty() is false (there is a value), we wouldn't display it if dsf.include is false? Should it be "or dsf.include" ?

Copy link
Contributor Author

@aliassheikh aliassheikh Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix was done here by comparing the statement with it before modification in 6.7 and set back 'and dsf.include' in the statement. To avoid any regression, nothing else is changed in this fix.

6.5

jsf:rendered="#{(
                (editMode == 'METADATA' or dsf.datasetFieldType.displayOnCreate        or !dsf.isEmpty() or dsf.required) and dsf.include)
                or (!datasetPage and dsf.include)}">

6.7

jsf:rendered="#{(
                (editMode == 'METADATA' or dsf.datasetFieldType.shouldDisplayOnCreate() or !dsf.isEmpty() or dsf.required or dsf.hasRequiredChildren))
                or (!datasetPage and dsf.include)}">

fix:

jsf:rendered="#{(
                (editMode == 'METADATA' or dsf.datasetFieldType.shouldDisplayOnCreate() or !dsf.isEmpty() or dsf.required or dsf.hasRequiredChildren) and dsf.include)
                or (!datasetPage and dsf.include)}">

Copy link
Member

@qqmyers qqmyers Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I think I've convinced myself that, because of

dataverse/src/main/java/edu/harvard/iq/dataverse/DatasetPage.java

Lines 1907 to 1911 in a843c84

for ( DatasetField dsf : mapDatasetFields.values()) {
if (dsf != null){
dsf.setInclude(true);
}
}
, include will always be true if the value is non-empty (in the dataset page) so adding and dsf.include won't break displaying existing values. (It does make me wonder whether or !dsf.isEmpty() is needed though (if you're not in metadata mode, could you have a pre-existing value that has to be displayed? Probably not worth worrying about.)

<!-- Primitive fields -->
<p:fragment id="editPrimitiveValueFragment" rendered="#{dsf.datasetFieldType.primitive}">
<p:autoUpdate/>
Expand Down