feat(admin): configurable display field and date field for collection list view

[austinkern]

Summary

Let collections override which field powers the Title column and which field powers the Date column in the admin content list (/content/:collection). Currently both are hardcoded to system fields (title and published_at), which breaks down whenever a collection has its own domain-specific equivalents.

Motivation

Two concrete cases on the same site:

1. employees collection — has name (the person's name, e.g. "Amy Morse") and title (their job title, e.g. "Commercial Lines Agent"). The list view's Title column shows title, so the list reads "Commercial Lines Agent / Office Mascot / Owner | Broker" instead of "Amy Morse / Buddy / John Shiflet". Editors have to read the role to find the person.

2. blog_posts collection — has pub_date (when the post was actually published, with real historical dates going back to 2019) but the Date column shows published_at. After a content import, every post shows the import date instead of its real publication date. We worked around this by UPDATE ec_blog_posts SET published_at = pub_date, but that's a data hack — it conflates "when did this go live in this CMS" with "when did the content originally publish."

Both pain points are the same shape: the admin assumes EmDash's system conventions match the collection author's intent, and when they don't, the editor sees the wrong value.

Proposed API

Two optional pointers on the collection definition:

{
  slug: "employees",
  label: "Employees",
  icon: "users",
  supports: ["drafts", "revisions"],
  displayField: "name",       // ← field slug used for the Title column
  dateField: "pub_date",      // ← field slug used for the Date column (and default list sort)
  fields: [ /* ... */ ]
}

• displayField defaults to title (current behavior).
• dateField defaults to published_at (current behavior).
• Validate that the named field exists on the collection at schema-write time.
• For dateField, prefer datetime field types; warn if it's string.

The admin list, content editor breadcrumbs, search results, and reference-field pickers should all use displayField once it's defined.

Alternatives Considered

• Rename the user-facing fields to title/published_at — distorts the data model to fit the UI. The semantics of "the employee's name" really aren't a title.
• Sync system fields to user fields via triggers/hooks — works for published_at, doesn't work for title (which is required + non-null + default '', so it'd need to be a separate displayed value somehow).
• Custom plugin pages — already doing this for the lead_notes collection, but it's a heavy hammer for "show the right column in a list."

Context

This is the same family of "make collection presentation configurable" as #1131 (hidden collections from sidebar). A displayField + dateField pair would resolve essentially every "the admin list shows the wrong thing for this collection" report.

Real-world install: an insurance site migrated to EmDash with imported blog posts (real dates back to 2019) and an employees collection where name is the canonical display.

[CacheMeOwside]

Thanks for opening this! The write-up is good, and the two concrete cases (employees.name and blog_posts.pub_date) make the need clear. Since this is on the 1.0 roadmap, I'm happy to pick it up.

Here's the approach I'm taking:

Goal

Let a collection choose which field powers the Title and Date columns in the admin content list.

Two new optional settings on a collection:

• displayField: field slug used for the Title column. Defaults to title (current behavior).
• dateField: field slug used for the Date column and default list sort. Defaults to the current behavior (the item's updated/created date).

Both optional, so existing collections are unchanged. No content migration, no breaking change.

Plan

1. Add two new optional columns - display_field and date_field - to the _emdash_collections table with a database migration (added to runner.ts). Leaving them empty means "use the default," so existing collections keep working exactly as before.
2. Make the create and update code accept displayField and dateField, save them, and return them when a collection is read back.
3. Check the values when they're saved. Don't allow a displayField or dateField that points to a field the collection doesn't have. For dateField, make sure it points to a date field. Either require it, or at least show a warning if it points to a plain text field.
4. Use the new columns or the default in the admin list. The default sort follows dateField.

Scope note

I'd prefer implementing the content-list Title + Date columns first (the core pain point), then wiring the other surfaces (breadcrumbs, search results, and reference-field pickers using displayField) in a follow-up so the first PR stays reviewable.