Dataverse displays to users information entered in certain compound fields in unexpected ways

[jggautier]

When does this issue occur?
When viewing a dataset page with information entered in the child fields of certain compound fields, where the child fields also include "displayFormats" to control how the information is shown to users.

Which page(s) does it occurs on?
The dataset view pages in the JSF version of Harvard Dataverse and in the Modern UI version of Harvard Dataverse

What happens?
On the JSF version of Harvard Dataverse, the user:

• Doesn't see the name of the parent field (such as "Geodetic Model")

• Sees the information in the child fields displayed on separate lines

• Sees the names of the child fields prepended to the information entered in the child fields, since "#NAME:" is included in those fields' displayFormats

  

On the Modern UI version of Harvard Dataverse, the user:

• Doesn't see the name of the parent field (such as "Geodetic Model")

• Sees the information in the child fields displayed on separate lines

• Does not see the names of the child fields, even though "#NAME:" is included in those fields' displayFormats

  

To whom does it occur (all users, curators, superusers)?
All users who see the dataset page on the JSF and Modern UI versions of Harvard Dataverse

What did you expect to happen?
On the JSF and Modern UI versions of Harvard Dataverse, the user:

• Sees the name of the parent field ("Geodetic Model")

• Sees the information in the child fields displayed on the same line

• Sees the names of the child fields prepended to the information entered in the child fields, since "#NAME:" is included in those fields' displayFormats

  

  This is how we expected Dataverse to show users this information when we were designing this part of the dataset page for datasets in the CIESIN collection. See Define and create CIESIN/SEDAC custom metadata block dataverse.harvard.edu#400 (comment).

  And this is how we expect Dataverse to display what users enter in the child fields of all compound fields where "#NAME:" is used to help users more easily understand the information.

Which version of Dataverse are you using?

• The JSF version of Harvard Dataverse on v. 6.10.1 build iqss-4
• The Modern UI version of Harvard Dataverse on v. 6.10.1 build iqss-4 | frontend version: 371cf9773

Any related open or closed issues to this bug report?

• CIESIN Metadata Block Display Format for Horizontal Datum Name and Ellipsoid Name dataverse.harvard.edu#481
• Change how UI shows compound fields #6589
• Feature Request/Idea: better visual representation of multiple fields #9675

[jggautier]

Do these bugs affect the readability of what users enter in other fields?
We found this bug because of how Dataverse is showing information entered in a particular field in a custom metadata block, customCIESIN, being used by managers of a collection in Harvard Dataverse.

I looked at the other fields in that metadata block and in other metadata blocks to see if the JSF or Modern UI versions of Dataverse display the information in ways we don't expect and I found two other cases where the JSF version displays the information how we expect, but the Modern UI doesn't:

• one involving the Horizontal Coordinate System Definition compound field, also in the customCIESIN metadata block
• one involving the Object Dimensions compound field in the "3D Objects Metadata" metadata block.

These examples show how the Modern UI doesn't display information entered in the "3D Objects Metadata" metadata block's Object Dimensions compound, but the Modern UI also displays information entered in the customCIESIN metadata block's Horizontal Coordinate System Definition compound field in the same way:

Unexpected display in Modern UI: The view page on Modern UI version of Harvard Dataverse shows the parent field name and the child field information on one line as expected, but seems to ignore displayFormats, making the information harder for users to understand:

Expected display in JSF: The view page on JSF version of Harvard Dataverse shows the information as expected, showing the name of the parent field, showing what's entered in the child fields on one line, and using the fields' displayFormats as expected:

[rtreacy]

I revised the data load to explicitly construct the Geodetic Model as specified and on the JSF side the Geodetic Model is now displayed as Julian said it should. However on the JSF side it still also displays 'Horizontal Datum Name' and 'Ellipsoid Name' as before. On the Modern UI the Geodetic Model is now displayed, but with only the two values (without the names - WGS84;WGS84). The 'Horizontal Datum Name' and 'Ellipsoid Name' are also displayed as before.

The following analysis is generated by Claude Opus 4.8 --
Why separate lines still appear
Issue #12652 documents exactly this. Even when the compound data is entered/stored correctly, current Harvard Dataverse (v6.10.1) mis-renders compound fields whose children have #NAME: in their displayFormat:
•
JSF UI: hides the parent name, shows children on separate lines, and prepends the #NAME: prefixes (Horizontal Datum Name: WGS84, Ellipsoid Name: WGS84).
•
Modern UI: hides the parent name, shows children on separate lines, and drops the #NAME: prefixes.
The expected behavior (per #12652) is: show the Geodetic Model parent name, put both children on the same line, and keep the #NAME: prefixes. That expected layout is a platform change that must be delivered in Dataverse itself — it's currently milestoned for 6.14 and still open.

Bottom line
You did everything correctly on your side. The lingering "separate lines" are the known Dataverse compound-field rendering defect (#12652), not a problem with your JSON, your .tsv, or the updated script — and it can only be resolved by a Dataverse platform release.

Modern UI-

JSF UI-

[rtreacy]

Where each rendering path lives

Compound-field display in the two UIs is driven by completely different code:

• Classic (JSF) UI → server-side rendered by the XHTML template src/main/webapp/metadataFragment.xhtml, which reads pre-formatted strings produced by DatasetFieldCompoundValue.getDisplayValueMap().
• Modern UI (SPA) → rendered client-side by the React app (separate dataverse-frontend repo), which consumes the dataset JSON produced server-side by src/main/java/.../util/json/JsonPrinter.java (DatasetFieldsToJson). The relevant backend code that feeds it is in this repo; the actual DOM/line layout code is in the frontend repo, not under ~/IQSS/dataverse/src.

That difference is exactly why #12652 reports two different symptoms (prefixes shown in JSF, prefixes dropped in Modern UI) for the same data.

---

1) Classic / JSF UI — metadataFragment.xhtml (compound block, lines ~128–183)

<ui:repeat value="#{dsf.datasetFieldCompoundValues}" var="compoundValue" ...>
  ...
  <ui:repeat value="#{compoundValue.displayValueMap.entrySet().toArray()}" var="cvPart" varStatus="partStatus">
    ...
    <!-- (A) separator between children is the PARENT's displayFormat -->
    <h:outputText value="#{dsf.datasetFieldType.displayFormat} "
                  rendered="${!partStatus.first and !settingsWrapper.isCvocField(cvPart.key.datasetFieldType.id)}"/>
    ...
    <!-- (B) child value string, already carrying the #NAME: prefix -->
    <h:outputText value="#{cvPart.value}" .../>
  </ui:repeat>
  <!-- (C) line break between *compound values* -->
  <ui:fragment rendered="#{not compoundValuesStatus.last}"><br/></ui:fragment>
</ui:repeat>

Problems here:

• (A) Line 132 — children are joined using the parent field's displayFormat as a separator, and only when !partStatus.first. The template has no notion of "show the parent name (Geodetic Model) then list the children under it"; it just concatenates children. The parent title is emitted only as the row <th> at line 72 (#{dsf.datasetFieldType.localeTitle}), which is not the grouped presentation Dataverse displays to users information entered in certain compound fields in unexpected ways #12652 expects.
• (B) cvPart.value is the string returned by getDisplayValueMap(), which is where the Horizontal Datum Name: / Ellipsoid Name: prefixes are baked in (see below). In JSF these prefixes therefore appear verbatim.
• (C) Line 180–182 — the <br/> is emitted between compound values. If the geodetic data is stored as two single-child compound values (rather than one compound value with two children), each lands on its own line — the "separate lines" symptom.

The prefix itself comes from DatasetFieldCompoundValue.getDisplayValueMap():

// src/main/java/edu/harvard/iq/dataverse/DatasetFieldCompoundValue.java  (~lines 176–197)
String format = childDatasetField.getDatasetFieldType().getDisplayFormat(); // e.g. "#NAME: #VALUE"
...
String displayValue = format
        .replace("#NAME", childDatasetField.getDatasetFieldType().getTitle())  // -> "Horizontal Datum Name"
        .replace("#EMAIL", ...)
        .replace("#VALUE", sanitizedValue);                                    // -> "WGS84"
fieldMap.put(childDatasetField, displayValue);   // "Horizontal Datum Name: WGS84"

So in JSF the #NAME: prefix is intentionally applied per child, but the surrounding template (A/C) fails to group them under the parent name on a single line — that is the JSF defect.

---

2) Modern UI — backend JSON in JsonPrinter.java (DatasetFieldsToJson, lines ~1438–1464)

The SPA never calls getDisplayValueMap(). It renders whatever the JSON API gives it, and the JSON is built here:

@Override
public void primitiveValue(DatasetFieldValue dsfv) {
    if (dsfv.getValue() != null) {
        valueArrStack.peek().add(dsfv.getValue());   // <-- RAW value only: "WGS84"
    }
}

@Override
public void endCompoundValue(DatasetFieldCompoundValue dsfcv) {
    JsonArray jsonValues = valueArrStack.pop().build();
    if (!jsonValues.isEmpty()) {
        JsonObjectBuilder jsonField = jsonObjectBuilder();
        for (JsonObject jobj : jsonValues.getValuesAs(JsonObject.class)) {
            jsonField.add(jobj.getString("typeName"), jobj);  // <-- nests children, no displayFormat applied
        }
        valueArrStack.peek().add(jsonField);
    }
}

Problems here (the backend half of the Modern-UI symptom):

• primitiveValue() (line ~1440) emits the raw child value (dsfv.getValue() → "WGS84"), never applying the child field's displayFormat. So the #NAME: (Horizontal Datum Name:) prefix is absent from the JSON — which is exactly why the Modern UI "does not see the names of the child fields."
• endCompoundValue() (line ~1455) groups the children into an object keyed by typeName but carries no parent display hint / ordering / same-line grouping metadata. The SPA thus has nothing telling it to render them under the Geodetic Model parent on one line, so it falls back to stacking them.

The final line-layout that puts children on separate lines is in the dataverse-frontend React components (a different repository); but its input is deficient because JsonPrinter supplies raw values without the child displayFormat and without parent-grouping information.

---

Summary of the "incorrect code"

UI	File	Culprit
JSF	src/main/webapp/metadataFragment.xhtml (lines ~132, ~180) + DatasetFieldCompoundValue.getDisplayValueMap() (lines ~176–197)	Children joined by parent displayFormat with <br/> between compound values; no "parent name + children on one line" grouping. #NAME: prefix applied here.
Modern UI	src/main/java/edu/harvard/iq/dataverse/util/json/JsonPrinter.java → DatasetFieldsToJson.primitiveValue() (line ~1440) and endCompoundValue() (line ~1455)	Emits raw child values without applying each child's displayFormat, and no parent grouping/display metadata → SPA drops #NAME: prefixes and stacks children. Final layout is in the separate dataverse-frontend repo.

Neither defect is fixable from your update_sedac_metadata.py or the customCIESIN.tsv; both are platform-side and are what #12652 must resolve.

[rtreacy]

JSF UI after data cleanup

Modern UI after data cleanup

[jggautier]

I was asked to show what the dataverse_json exports look like for datasets where users see the information the way we expect and don't expect, so I'll post that here.

For a dataset where users can see the information the way we expect, here's how that information is organized in the dataverse_json export for the draft version of the doi:10.7910/DVN/U7MOCL dataset in @rtreacy's screenshots above:

{
    "displayName": "CIESIN Metadata Block",
    "name": "customCIESIN",
    "fields": [
        {
            "typeName": "geodeticModel",
            "multiple": false,
            "typeClass": "compound",
            "value": {
                "horizontalDatumName": {
                    "typeName": "horizontalDatumName",
                    "multiple": false,
                    "typeClass": "primitive",
                    "value": "WGS84"
                },
                "ellipsoidName": {
                    "typeName": "ellipsoidName",
                    "multiple": false,
                    "typeClass": "primitive",
                    "value": "WGS84"
                }
            }
        }
    ]
}

For a dataset where users can see the information in a way we don't expect, here's how that information is organized in the dataverse_json export for the draft version of the doi:10.7910/DVN/RBTUXN dataset:

{
    "displayName": "CIESIN Metadata Block",
    "name": "customCIESIN",
    "fields": [
        {
            "typeName": "geodeticModel",
            "multiple": false,
            "typeClass": "compound",
            "value": {
                "horizontalDatumName": {
                    "typeName": "horizontalDatumName",
                    "multiple": false,
                    "typeClass": "primitive",
                    "value": "WGS84"
                },
                "ellipsoidName": {
                    "typeName": "ellipsoidName",
                    "multiple": false,
                    "typeClass": "primitive",
                    "value": "WGS84"
                }
            }
        },
        {
            "typeName": "horizontalDatumName",
            "multiple": false,
            "typeClass": "primitive",
            "value": "WGS84"
        },
        {
            "typeName": "ellipsoidName",
            "multiple": false,
            "typeClass": "primitive",
            "value": "WGS84"
        }
    ]
}