If resource is not a periodical then date display should be <<YYYY>>

Just making notes from a discussion and I had today:

• If we are passed a date in a specific format/level of granularity, we should display as it is passed to us - i.e. if we are passed YYYY we should display YYYY

• I'm concerned about putting business logic about remote objects (i.e. eHoldings resources) into the Agreements front-end - this feels really not the right place for this decision to happen, and creates dependencies if eHoldings changes/expands the types it supports

• Some options for going forward might be:

  • Just say Agreements displays dates as we receive them from other sources

  • Support a date display template to be passed alongside resources so Agreements can be told how to display the dates for different resources/resource types

  • Support a user configurable list of resource types and display options in Agreements so the user can configure this for the tenant and is responsible for managing the display of dates (with the default being 'display as passed'). This is a compromise position as it keeps Agreements as the place where the business logic is applied, but it isn't hard coded in to the App

- if a date is available, EKB always passes in this format YYYY-MM-DD. So the frontend is handling this requirement.

I think at the moment we are getting a coverage range on all types. Do you have/can EKB pass a specific date of publication where it exists?

I had a conversation about book publication dates with a couple of days ago and he suggested we need to extend the datamodel in Agreements to support this - I suspect this would need to be the underlying solution for fixing the display issue (as currently the single publication dates seem to be treated as coverage ranges.)

What do you think?