Skip to content

Conversation

@mikejritter
Copy link
Contributor

What does this do?

  • This updates the behavior of the csv export to treat TermRefs as separate from AuthRefs

Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-1837

When adding the ability to include the authority type, TermRefs were also impacted because they are under the Vocabulary authority. This however was unexpected behavior from the user side of things as that is generally something which is hidden when interacting with the backend. This updates the CSV export only to continue to treat Terms how they have been previously.

In order to do this I used a Table from guava so that we did not need to maintain a map of map of maps, and instead could use both the part name and Term/Auth keys to put data into buckets. I also created an extra enum to differentiate Term/Auth and Standard fields, and switched from booleans in order to have some more control over what actions to take as just checking if a field was a ref wasn't enough.

How should this be tested? Do these changes have associated tests?

  • Rebuild CollectionSpace
  • Create an object with the following fields:
    • object number, responsible department, annotation author, dimension -> measured by, owner
    • For repeating fields, feel free to use any number of entries
    • Please include at least one field which is in a different xml namespace, in this example I used annotation author as it is in collectionobjects_annotation. I had noticed issues with de-urning when testing but believe it is fixed.
  • Query the export API for a csv and see the correct output
{
  "ns2:invocationContext": {
    "@xmlns:ns2": "http://collectionspace.org/services/common/invocable",
    "mode": "list",
    "outputMIME": "text/csv",
    "includeFields": {
      "field": [
        "collectionobjects_common:objectNumber",
        "collectionobjects_common:responsibleDepartments/responsibleDepartment",
        "collectionobjects_annotation:annotationGroupList/annotationGroup/annotationAuthor",
        "collectionobjects_common:measuredPartGroupList/measuredPartGroup/dimensionSubGroupList/dimensionSubGroup/measuredBy",
        "collectionobjects_common:owners/owner"
      ]
    },
    "docType": "CollectionObject",
    "listCSIDs": {
      "csid": [
        "${OBJ_CSID}"
      ]
    },
    "params": [
      {
        "param": {
            "key": "includeauthority",
            "value": "true"
        }
      }
    ]
  }
}

Dependencies for merging? Releasing to production?
None

Has the application documentation been updated for these changes?
The export service is undocumented and needs documentation.

Did someone actually run this code to verify it works?
@mikejritter tested using a local install


private CSVPrinter csvPrinter;
private Map<String, Map<String, Set<String>>> refFieldsByDocType = new HashMap<>();
private Map<String, Table<String, String, Set<String>>> refFieldsByDocType = new HashMap<>();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Storing the doc type seems unnecessary but I wasn't sure if there could ever be a collision for partNames. It seems unlikely as the export only works on a single docType at a time (though core fields can be exported as well). Maybe it would be worth it though to change.

@mikejritter mikejritter requested a review from spirosdi December 16, 2025 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant