Catalog search and work pages displaying "date issued" metadata field tag

[KatharineV]

Summary

Prior to Knapsack, our catalog search and work pages were configured to show the date issued field with the label "Date," not "Date issued." Post Knapsack, the work page and the catalog search metadata preview is displaying "Date issued," which is terminology that doesn't make sense for some of our works. It is also inconsistent because the back-end of the UI still calls the field in question "Date," so we need that consistency between field labels to return.

Acceptance Criteria

• date issued label should display as Date

Screenshots or Video

Screenshots of ADL and SDAPI production site catalogs prior to Knapsack. Dates are 3/2023, 7/2023 (ADL), and 1/2024 (SDAPI):

Screenshots of ADL and SDAPI production site catalogs post Knapsack, taken today:

Back-end of a work on ADL, which still shows "Date" as the label for the field that is reverting to "Date issued" on the work page and in the catalog search.

The front end of that same work, which shows "Date issued" for the field that is called "Date" on the back-end:

Testing Instructions

Expected Behavior Before Changes

Date issued metadata tag displays 'Date issued'

Expected Behavior After Changes

Date issued metadata tag displays 'Date'

Screenshots / Video

Before

After

Notes

[K8Sewell]

PR ready for review - #809

[ShanaLMoore]

QA RESULTS: ✅ PASS

tested on STAGING

COLLECTION ⚠ NEEDS REVIEW

• date issued label should display as Date. Yes but...

This collection duplicate Date fields now. Which date fields is correct?

WORKS ✅

• date issued label should display as Date

[ShanaLMoore]

I originally marked this as NEEDS REWORK because I thought we introduced a bug for the collection. However, production behaves the same way.

ref: Collection

Because of this, we've technically have reached feature parity and completed the original ask. A separate ticket should be made to address the duplicate Date fields on the collection form, if the client deems it to be an issue.

Furthermore, removing one of the date properties from the collection may be risky because prod data could be using either or both. We'd be at risk of losing data if both no longer exists when converting them to valkyrie.

[KatharineV]

I've known about the duplicate date labels from day one. It's a leftover bug that my predecessor introduced when he was customizing our tenant. I agree that feature parity is met. No problems remain.