Making the content list usable on large collections: sort, filter, and plugin columns

[logelog]

The problem

#2179 asks for admins to be able to customize content list columns, especially with custom fields. Working through it, the column display turns out to be the smallest part. Once a collection has a few hundred entries and a custom field worth looking at, you also want to sort and filter by it, and today both of those happen in the browser over the loaded page only. On a large collection that gives you the wrong answer rather than a slow one.

What I am proposing

Four pieces, each independently reviewable:

1. Configured columns. Collections declare admin.listColumns, and the content list renders those scalar custom fields. Display only. This follows Discussion #1717 and is open as #2194.

2. Server-side sorting and filtering on explicitly indexed fields. A field opts in with an indexed flag, which creates a real index. The list can then order by it (#2212) and apply schema-validated filters to it (#2213), both server-side, with cursor pagination preserved. Only scalar types can be indexed, and the registry rejects the flag on anything else.

3. Plugin-contributed columns. Trusted plugins contribute typed, computed columns while EmDash keeps ownership of the table, ordering and pagination (#2195).

4. The admin controls on top. A validated indexed flag in the field editor, a value dropdown on indexed enum columns, sort headers on eligible columns, and filter serialization in the admin API client. This is the part a user actually touches. I have not opened it as a PR yet because it depends on 1, 2 and 3 landing first, and because its shape depends on what you want those contracts to look like. Including it here so it is covered by the same conversation rather than needing its own later.

What it looks like

emdash-content-list-demo.mp4

Posts with Priority, Ticket number and Workflow State as columns, sortable headers, a value dropdown on Priority, and search finding an entry by its ticket number. That covers pieces 1, 2 and 4, plus the searchable-fields fix in #2191. Piece 3, plugin-contributed columns, is not in the recording.

Open questions

Two things I would genuinely like your call on:

• Is an explicit indexed flag the right opt-in? The alternative is inferring it from field type and usage, which is friendlier but makes the index harder to reason about.
• For plugin columns, is host-owned ordering the right boundary? A plugin can contribute a value today but nothing to sort it by, so a computed column ends up readable but not orderable. Opening that up is a bigger contract, so I left it out rather than guess.

On the order these arrived in

These went up as PRs before this Discussion existed, which is the wrong way round per CONTRIBUTING. The topic itself was not mine: it came from the blog team through #2179, and when priorities came up on Discord in July, kodster28's issues were pointed at as the ones most likely to be merged. I took that as the direction being settled and went straight to the code. That was me reading approval into something that was not one, and this thread is the step I skipped. Happy to close any or all of the PRs if the direction is not what you want.