Dates appear just fine in search results for v.2.7.0. Looks great!

: i think i followed up via email about this at some point, but never on JIRA, so I'm doing that now.

Anyhow, I never submitted a pull request for my current approach because it was just a hack that was implemented in haste. In any event, here's the gist of it: https://github.com/YaleArchivesSpace/yale_pui_customizations/blob/master/public/views/shared/_result.html.erb#L47-L73

Ideally that should be handled a better way. Also, I'm not filtering out things like "digitization" dates, etc., simply because we aren't using those locally.

Last, another reason not to handle this in the view is because I've noticed that I still need to add some other filters based on records types. Agents, for instance, I think also have "dates" associated with material descriptions embedded in their JSON results, and those shouldn't display in an agent search result.

I hope that helps, but please let me know if there are any questions, etc.

- we'd be very interested in a pull request for what you've done for Yale in this area.

Long story short:

Dates did not get added to the search results due to running out of time. They should be added.

When added, the use of the "display title" for archival objects should be reconsidered. Also, multiple dates should be concatenated in a sensible way, rather than ignored, but you'd want to restrict what types of dates to display so as only to include inclusive or single dates about "creation". I don't think that would be hard to do, but it would require a bit of thought and testing.

And doing this should clear things up for the treeview, and the PDF view, as well.

Plus, it will make things much more clear to users when they search, sort, or filter by dates

: yes, i do remember this one... and it basically boiled down to needing more development attention at some point due to how dates and the "display titles" work in ASpace right now.

As i recall, the group was in favor of not using the display title as the title (which ASpace creates by concatenating the title along with the first date subrecord), but then conditional logic would need to be added to be able to use the dates in the case that a title was absent. I think it's odd that ASpace only uses the first date in these cases (since date subrecords can repeat), so in hindsight, here's what I think would be the simplest solution:

• Make titles inherited, without the ability to turn that feature off (which someone could do now). That way, you always have a title that you can use in the search results screen without concatenating the first date. (Or, I suppose if someone really wanted to turn that off, then you could default to some other text when it was missing, such as "[untitled]" so that a link could still be provided, but that would be a lot less user friendly.)

• Go back to the Cherry Hill design here (and elsewhere in the interface) and put the dates on a separate line. But this is somewhat tricky, since ASpace can have multiple dates. But my preference would be to only include a few dates, like creation, broadcast, and published. You definitely don't want to include every possible date here, like digitized date, etc., but those shouldn't need to display on a search-result screen or a treeview.

If that's done, then the same logic could be followed in the right-hand treeview, with both titles and dates for each and every component. But, we never got to see what such a thing would look like in a real-world setting, so it's hard to say if that design feature would hold up. Here's what I mean, though:

And, of course, the same logic could be used in the PDFs. I believe that the display title is used there, as well, so in the cases when a component just has a single date (which is the most frequent case), you get doubled-up dates that add no value, really. But, I also don't think it's a great idea to concatenate date information at the end of the the title, since then it's not clear if the date(s) is part of the title, or actually meant to convey something else altogether, so that's why I do prefer the Cherry Hill design for splitting those elements. But I do think that date information could be consolidated and concatenated on the search-result page and the treeview, so that you wouldn't end up with dates being put on different lines. e.g.:

• 1900

• 1911-1927

• 1945-1954

Would be better expressed as "1900, 1911-1927, 1945-1954".

Last, we didn't talk much about bulk dates, as I recall, and although I would understand the argument for adding that to the search-result page for collection-level results, my preference would be to keep the bulk dates confined to the actual landing pages, as they are now.