Store publication date

[elrayle]

Description

It is helpful to know when an exhibit was published. This can be used to sort exhibits.

Use Case

Sort the display of exhibits on the home page with most recently published exhibits appearing first.

Possible Solutions

Store the date in the database. Two options proposed.

OPTION 1 - Use existing published_at data base field in table spotlight_exhibits

Currently, published_at is always NULL and code does not change the value.

Workflow:

• Set published_at automatically when an exhibit is published for the first time.
• Allow for setting the value of published_at manually through the Exhibit’s Dashboard -> Configuration: General -> Basic settings form to change the date if needed (e.g. publication was accidentally published, publication is temporarily unpublished and is re-published, publication date is NULL)

OPTION 2 - Use first_published_date and last_published_date fields in table spotlight_exhibits

NOTE: The use of two fields was proposed by @ggeisler in Slack discussions. Please add a clarification if this doesn't capture your description accurately.

first_published_date will replace published_at field. last_published_date will be a new field.

Workflow:

• Set first_published_date and last_published_date automatically when an exhibit is published for the first time.
• Update last_published_date automatically when exhibit is unpublished and later re-published.
• Allow for setting the value of last_published_date manually through the Exhibit’s Dashboard -> Configuration: General -> Basic settings form to change the date if needed.

NOTE: Setting manually through the form will also set first_published_date if the value is currently NULL. This allows for repository managers to set the publication date for existing published exhibits.

[ggeisler]

@elrayle Thanks for writing up the detailed options. I do agree we can do something useful here. My main concerns (which are relevant to either option) have to do with allowing the curator to manually set publish dates and adding a new UI element to support that action. So my first thought is that if we go with Option 2, then at least we could ensure (for exhibits added after the feature is enabled) that we have one date (first_published_date) that is not controlled by the curator and is an accurate reflection of when the exhibit truly was first published.

I do get the idea that in some cases an exhibit curator might want to indicate a major new version without unpublishing and re-publishing the exhibit. And you bring up a good point that all of our existing exhibit would have null values that might need to be populated in some way. But here are some things that concern me about the manually populated aspect of the options:

• This would mean we have to add a new field on the General settings page, and we'd probably have to add extra instructions to explain what it's for, as well as error checking to make sure it’s a valid date. Are we sure that there are enough real use cases where an exhibit curator wants to indicate a major new version without unpublishing and re-publishing the exhibit to justify making the General settings page more complicated for all curators (the vast majority of which, at least at Stanford, publish their exhibit once and thereafter only make minor updates, if any, and thus don't care about indicating a last published date)?

• If the number of expected use cases is small, perhaps we could we solve it by just having some documentation that tells curators that if they want to update their exhibit’slast_published_date value, they can do so by unchecking and rechecking the “Publish” checkbox? That’s admittedly kind of kludgy, but if the scenario is rare, I wonder if that’s better than displaying a new form field to every curator, even though very few curators will care about it? (Not to mention it would eliminate a lot of the work necessary to implement the UI part.)

• Are we okay with accepting potentially untrue values for the last_published_date? If you intend to use this field as a sorting field, I wonder if making it a manually-updated field is wise, since curators could in theory game the system by giving their exhibit a more recent published date in order to get their exhibit to show up higher in the sort order. (They could also do so with the automated approach, but that might be less obvious than a field where they actually enter any date they want.)

I guess where I'm at is I do agree we can do something useful here, but I’m wondering if we are better off (at least with a first pass at it) making it an entirely automated thing based on the Publish checkbox (Option 2 without the third workflow step), rather than getting into all of the concerns and extra work that come up with making it a user-controlled thing. But I'm interested to hear your thoughts.

[ggeisler]

@elrayle Another question I forgot to ask above, aside from using a published_date field for exhibit sorting, do you plan to expose that value anywhere in the UI (either at the site or exhibit level)?

[elrayle]

@ggeisler I don't feel strongly about the field for manually setting either published date. I agree that this will be rare. I can create something temporary to retroactively set publish dates on our existing exhibits.

RE: exposing the published date - I might consider a blurb next to the published checkbox, something like published since August 3, 2021 (using the first_published_date as the date. I wouldn't expect to expose it to the general public.

We are looking at adding a Featured Exhibits page that will highlight 4 exhibits at a time and I am looking at using the published date to select 4 that are distributed across publication dates so that there is always a newer exhibit combined with an older exhibit and two in between.

[ggeisler]

@elrayle Okay, great. I think if we can avoid the manual publish date setting that alleviates a lot of my concerns around complicating the General settings page. From a Stanford perspective I don't think we'd have use for more than the first_published_date field, but I do understand how your Featured Exhibits use case might benefit from the last_published_date field so you can surface updated exhibits.

It would be good to get another developer viewpoint on this, though. I think @cbeer might have some thoughts.

[elrayle]

@ggeisler I'm fine with first_published_date and revisiting last_published_date later if that doesn't seem sufficient. I'd be fine if we use the existing field published_at, which currently is a date that is always NULL.

If you prefer first_published_date, do you want to change the name of published_at to be first_published_date or add a new field and leave published_at as it currently is?

[ggeisler]

@elrayle Sounds good.

I like the idea of sticking with the current published_at field. If and when we decide there is value in an additional publication date, we could decide then what might be the most clear names for the fields and rename published_at if it makes sense.

[cbeer]

:+1: to sticking with the published_at field