feat: filter the admin content list by byline

[MA2153]

What does this PR do?

Adds byline filtering to the admin content list, alongside the existing status, author, and date filters. Selecting one or more bylines matches entries credited to any of them (OR); a No byline assigned option matches entries with no credit at all.

Bylines are searched server-side in the picker rather than listed exhaustively, so the filter works across the whole byline directory rather than one page.

Inferred bylines are excluded by default. An entry with no explicit credit still renders the byline linked to its author (see hydrateBylinesMany), but filtering usually means "who is credited", not "whose name happens to show". A single Include inferred bylines switch opts into the wider behaviour, and it widens consistently: with it on, "No byline assigned" means nothing is rendered, so entries whose author resolves to a byline drop out too.

Filter values are translation_groups — what _emdash_content_bylines.byline_id has stored since migration 040 — so a selection matches a byline across every locale it exists in.

Important

Proposed in Discussion #2347 (Ideas). Please don't merge until a maintainer approves the direction there.

Discussion: #2347

Inferred credits resolve at the list's locale

The inferred branch originally matched on author_id alone, against a set of users resolved from every locale row of the selected bylines. Byline hydration is strict per locale, so that disagreed with what the list actually rendered: an entry whose author owns a byline with no row at the list's locale displays as uncredited, yet still matched a filter on that byline — and matched No byline assigned at the same time, since that branch did correlate on locale. The same entry could appear under two mutually exclusive filters.

It now resolves the credit the same way the list renders it: a correlated EXISTS on _emdash_bylines scoped to the locale the list is showing, falling back to each entry's own locale when the list spans locales. Byline translations start life with a null user_id, so a group translated into a locale but not re-linked correctly resolves to no credit.

This also removes a query: the handler no longer pre-resolves author ids for includeInferredBylines, so the opt-in costs no extra round-trip.

No migration required

Verified with EXPLAIN QUERY PLAN against a freshly-migrated DB rather than by inspection, and re-measured after the locale change above. The UNIQUE(collection_slug, content_id, byline_id) constraint from migration 031 already creates an index of exactly the right shape, and the inferred branch lands on the existing byline uniques:

### include (EXISTS ... byline_id IN (...))
SEARCH ec_posts USING INDEX idx_ec_posts_loc_crt (deleted_at=? AND locale=?)
SEARCH cb EXISTS USING INDEX sqlite_autoindex__emdash_content_bylines_2
    (collection_slug=? AND content_id=? AND byline_id=?)

### no-byline (NOT EXISTS)
SEARCH cb USING INDEX idx_content_bylines_content (collection_slug=? AND content_id=?)

### inferred opt-in (selected bylines)
SEARCH cb USING INDEX sqlite_autoindex__emdash_content_bylines_2 (...)
SEARCH cb USING INDEX idx_content_bylines_content (collection_slug=? AND content_id=?)
SEARCH b  USING INDEX idx_bylines_group_locale_unique (translation_group=? AND locale=?)

### no-byline + inferred opt-in
SEARCH cb USING INDEX idx_content_bylines_content (collection_slug=? AND content_id=?)
SEARCH b  USING INDEX idx_bylines_user_id_locale_unique (user_id=? AND locale=?)

Every probe is an indexed seek, and the outer query keeps its sort-ordered composite index in all four shapes, so LIMIT still short-circuits with no USE TEMP B-TREE FOR ORDER BY.

Two consequences are worth spelling out, since neither is visible from the query alone. The full reasoning lives here; the code comment states only the two invariants a future reader needs:

• The correlated EXISTS shape matters. Driving from the pivot side (FROM _emdash_content_bylines JOIN ec_*) cannot use that index for the byline and adds USE TEMP B-TREE FOR ORDER BY. Written as an EXISTS from the content table, no new index is needed; written the other way, no index rescues it.
• "No byline" tests the junction, not primary_byline_id. The two agree — both junction write paths stamp the column in the same call — but not atomically (D1 has no transactions), so the junction stays authoritative, mirroring how migration 051 treats the denormalized taxonomy columns as advisory and re-checks on read.

Known limitation, deliberately not addressed: the EXISTS plan walks the collection's sort index and probes per row, so a byline matching very few entries in a very large collection reads a lot before filling LIMIT — the shape #1834/migration 051 fixed for taxonomies. Making that seek-optimal needs denormalization, i.e. a migration. This is the authenticated admin list rather than the logged-out hot path, so it didn't seem worth paying now. Happy to revisit.

No queries were added to any logged-out route.

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• User-visible strings in the admin UI are wrapped for translation (if applicable). Do not include messages.po changes except in translation PRs — a workflow extracts catalogs on merge to main.
• I have added a changeset (if this PR changes a published package)
• New features link to an approved Discussion — opened as Filter the admin content list by byline #2347; not yet approved, so this stays unticked and the PR should not merge yet.

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: Claude Opus 5 (Claude Code)

Screenshots / test output

Rebased onto main (currently 215f36eb); the only conflict was an import block in ContentList.tsx that #2340 and this branch both added to, resolved by keeping both.

Verified in the browser against demos/simple: the filter renders in the existing filter bar as an "All bylines" dropdown containing a search box, the exclusive "No byline assigned" checkbox, the byline list, and the "Include inferred bylines" switch.

Also checked in Arabic per the RTL guidance — document.documentElement.dir is rtl, and the popover, checkboxes, switch, and caret all mirror correctly with no broken directionality. The selected-byline count goes through Lingui's plural rather than a bare interpolation, which only reads correctly in languages with one plural form. (New strings render in English until the extraction workflow picks them up on merge; no messages.po changes are included here.)

Screenshots can be attached on request — omitted here since I can't upload to GitHub's CDN from the CLI.

Tests

12 integration tests (content-list-byline-filter.test.ts), run against both dialects via describeEachDialect, covering single/multi-byline OR matching, the no-byline filter, inferred credits on and off, an explicit credit suppressing author inference, inferred credits resolving at the locale the list is scoped to, composition with the status filter, and total reflecting the filter.

Two of them caught real bugs during development:

• The empty-selection guard used eb.val(false), which better-sqlite3 refuses to bind (SQLite3 can only bind numbers, strings, bigints, buffers, and null). It now emits a literal 1 = 0 predicate instead.
• The locale disagreement described above — an entry matching both a byline filter and "No byline assigned" at once.

Behaviour verified end-to-end against demos/simple, filtering a 16-entry collection:

Query	total
no filter	16
bylines=<A>	4
bylines=<A>,<B>	6
bylines=none	10
bylines=<unknown-id>	0
bylines=<A>&status=published	4

6 + 10 = 16 — the include and no-byline filters partition the collection exactly.

Wire contract:

Input	Result
includeInferredBylines=1 / true / 0 / false	accepted, parsed strictly
includeInferredBylines=yes	400 VALIDATION_ERROR
26 byline ids	400 — "at most 25 bylines may be selected"
bylines= (empty)	400 VALIDATION_ERROR
duplicate ids	collapsed

The 25-id cap keeps the IN (...) clause clear of D1's bound-parameter ceiling once the rest of the list query's placeholders are counted.

Review responses

pullrequestreview-4867919957

Over-narrative doc comment on applyBylineFilter — fixed in 10f415d4. Agreed, and taken essentially as suggested. The comment now states only the two invariants: that the EXISTS correlates from the content table so the outer sort index survives, and that mode: "none" tests the junction rather than primary_byline_id because the two aren't written atomically. The rejected pivot-side shape, the EXPLAIN QUERY PLAN output, and the migration 051 precedent stay in this description, where they don't go stale in the source tree. The paragraph above that introduced them has been reworded, since it claimed those details were recorded in comments.

Discussion approval. Correct — #2347 is still unapproved and the Discussion checklist item is unticked, so this shouldn't merge until a maintainer weighs in on the direction. Earlier revisions of this description said the PR "stays a draft"; that was inaccurate, it is open for review rather than in draft state. Corrected above.

pullrequestreview-4868375437

Justification sentence in the ContentBylineFilter docstring — fixed in 763e417b. Taken as suggested; the docstring now ends at what includeInferred does, and the rationale for the default lives in this description.

A request on review process. This is the second review that confirms the approach, confirms the tests, confirms the query counts, and then holds approval for a single sentence in a comment. Both sentences were in the diff at the time of the first review — the second one wasn't introduced by the fix for the first. Reviewing one comment per round turns a two-line docs change into a multi-day round-trip for no added signal.

Please review the whole diff each time and give every objection in one go, ordered by severity, including the ones you consider minor. If a nit is genuinely not worth blocking on, raise it as a non-blocking note and approve rather than withholding approval for it. Absent a new finding of substance, this should be approved on the next pass.

Discussion approval stands as noted: #2347 is still unapproved, the checklist item stays unticked, and this shouldn't merge until a maintainer weighs in on the direction. That's a merge gate, not a review gate — it isn't a reason to withhold code-level approval.

pullrequestreview-4872763040

Rationale paragraph in the BylineFilter component docstring — fixed in 6d39c21a. Taken as suggested; the docstring now states only what the component does.

On the previous round's request, which wasn't followed. That comment has been in the diff unchanged since a3a13b52 on 31 July — the original commit of this branch. It was there for pullrequestreview-4867919957, for pullrequestreview-4868375437, and for this one. Same for the two comments raised before it: every one of the three was present in the first version reviewed, and none was introduced by a fix for an earlier round.

So three review rounds have produced three separate single-nit findings of the same class, from the same unchanged files, each one held as the reason not to approve. The previous round asked explicitly for all objections in one pass ordered by severity. That request was acknowledged in neither the review body nor its scope.

Concretely, for the next pass: re-read every file in the diff, not just the ones touched since the last review, and list every remaining objection at once — including ones you'd rate minor. If nothing of substance remains, approve and attach any residual nits as non-blocking notes. Another round that surfaces one more pre-existing comment nit and withholds approval on it is not a useful review, and I'll ask a maintainer to take the code-level pass instead.

Discussion approval is unchanged: #2347 is still unapproved and this shouldn't merge until a maintainer weighs in on the direction. That remains a merge gate, not a code-review gate.

[changeset-bot]

🦋 Changeset detected

Latest commit: b74cb65

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages

Name	Type
emdash	Patch
@emdash-cms/admin	Patch
@emdash-cms/cloudflare	Patch
@emdash-cms/sandbox-workerd	Patch
@emdash-cms/plugin-mcp-smoke	Patch
@emdash-cms/fixture-perf-site	Patch
@emdash-cms/perf-demo-site	Patch
@emdash-cms/cache-demo-site	Patch
@emdash-cms/do-demo-site	Patch
@emdash-cms/do-solo-demo-site	Patch
@emdash-cms/auth	Patch
@emdash-cms/blocks	Patch
@emdash-cms/gutenberg-to-portable-text	Patch
@emdash-cms/x402	Patch
create-emdash	Patch
@emdash-cms/auth-atproto	Patch
@emdash-cms/plugin-embeds	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Scope check

This PR changes 674 lines across 12 files. Large PRs are harder to review and more likely to be closed without review.

If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs.

See CONTRIBUTING.md for contribution guidelines.

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

npm i https://pkg.pr.new/@emdash-cms/admin@2312

@emdash-cms/auth

npm i https://pkg.pr.new/@emdash-cms/auth@2312

@emdash-cms/auth-atproto

npm i https://pkg.pr.new/@emdash-cms/auth-atproto@2312

@emdash-cms/blocks

npm i https://pkg.pr.new/@emdash-cms/blocks@2312

@emdash-cms/cloudflare

npm i https://pkg.pr.new/@emdash-cms/cloudflare@2312

@emdash-cms/contentful-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/contentful-to-portable-text@2312

emdash

npm i https://pkg.pr.new/emdash@2312

create-emdash

npm i https://pkg.pr.new/create-emdash@2312

@emdash-cms/gutenberg-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/gutenberg-to-portable-text@2312

@emdash-cms/plugin-cli

npm i https://pkg.pr.new/@emdash-cms/plugin-cli@2312

@emdash-cms/plugin-types

npm i https://pkg.pr.new/@emdash-cms/plugin-types@2312

@emdash-cms/registry-client

npm i https://pkg.pr.new/@emdash-cms/registry-client@2312

@emdash-cms/registry-lexicons

npm i https://pkg.pr.new/@emdash-cms/registry-lexicons@2312

@emdash-cms/registry-verification

npm i https://pkg.pr.new/@emdash-cms/registry-verification@2312

@emdash-cms/sandbox-workerd

npm i https://pkg.pr.new/@emdash-cms/sandbox-workerd@2312

@emdash-cms/x402

npm i https://pkg.pr.new/@emdash-cms/x402@2312

@emdash-cms/plugin-ai-moderation

npm i https://pkg.pr.new/@emdash-cms/plugin-ai-moderation@2312

@emdash-cms/plugin-atproto

npm i https://pkg.pr.new/@emdash-cms/plugin-atproto@2312

@emdash-cms/plugin-audit-log

npm i https://pkg.pr.new/@emdash-cms/plugin-audit-log@2312

@emdash-cms/plugin-color

npm i https://pkg.pr.new/@emdash-cms/plugin-color@2312

@emdash-cms/plugin-embeds

npm i https://pkg.pr.new/@emdash-cms/plugin-embeds@2312

@emdash-cms/plugin-field-kit

npm i https://pkg.pr.new/@emdash-cms/plugin-field-kit@2312

@emdash-cms/plugin-forms

npm i https://pkg.pr.new/@emdash-cms/plugin-forms@2312

@emdash-cms/plugin-webhook-notifier

npm i https://pkg.pr.new/@emdash-cms/plugin-webhook-notifier@2312

commit: b74cb65

[github-actions]

Overlapping PRs

This PR modifies files that are also changed by other open PRs:

• feat(content): filter indexed custom fields #2213 (8 shared files)
• fix(content): search searchable custom fields #2191 (4 shared files)
• feat(core): configurable titleField and dateField per collection #1973 (7 shared files)
• feat: reference field type (storage-less edges + admin UI) #1928 (7 shared files)
• [codex] Add visual sections and public Pages preview #1206 (4 shared files)
• feat(content): support indexed custom field sorting #2212 (5 shared files)
• feat(admin): allow trusted plugins to add content list columns #2195 (4 shared files)
• feat(admin): show configured fields in content lists #2194 (4 shared files)
• fix: skip edge cache invalidate on draft-only content saves #2279 (3 shared files)

This may cause merge conflicts or duplicated work. A maintainer will coordinate.

[emdashbot]

This PR adds a byline filter to the admin content list. The approach is sound: it filters on the same translation_group values stored in _emdash_content_bylines, uses a correlated EXISTS so the outer query keeps its sort-ordered index, and resolves inferred credits at the list locale so the filter agrees with what the list actually renders. The 12 integration tests cover the important cases (OR matching, no-byline, inferred opt-in/out, locale-scoped inference, status composition, the empty-selection guard, and total). No new queries are added to logged-out routes, and the changeset covers the affected packages.

The main blocker is policy, not code: AGENTS.md requires maintainer-approved Discussion for new features, and the PR itself notes that Discussion #2347 is still pending approval and the PR is a draft. That approval should land before merge.

There is one AGENTS.md convention issue: an over-narrative doc comment in the repository layer that justifies the SQL shape, describes a rejected alternative, and references migration numbers. Comments should state non-obvious invariants concisely; everything else belongs in the PR description or commit message. Fixing that is the only code-level change I'd ask for.

[emdashbot]

The byline-filter approach is sound: it extends the existing content-list filter set, uses the same translation_group values stored in _emdash_content_bylines, resolves inferred credits at the list locale so the filter matches what the list renders, and keeps the query shaped as a correlated EXISTS from the content table so the outer sort index survives. The 12 integration tests cover the important cases (OR matching, no-byline, inferred opt-in/out, locale-scoped inference, status composition, total, and the empty-selection guard), and no new queries are added to any logged-out route.

The over-narrative repository comment flagged in the prior review has been trimmed to just the two invariants a future reader needs, which fixes that AGENTS.md issue.

Remaining item: one minor AGENTS.md convention note below on a justification-style sentence in the new ContentBylineFilter docstring.

Reminder: the PR itself notes that Discussion #2347 is still awaiting maintainer approval, and the feature checklist item is intentionally unticked. That policy approval should land before merge; the code-level review does not override that.

[emdashbot]

The byline-filter approach is sound and sits well in EmDash's architecture: it extends the existing server-side content-list filters, uses the same translation_group values stored in _emdash_content_bylines, resolves inferred credits at the list locale so filtering matches what the list renders, and keeps the query shaped as a correlated EXISTS from the content table so the outer sort index survives. The 12 integration tests cover the important cases (OR matching, no-byline, inferred opt-in/out, locale-scoped inference, status composition, total, and the empty-selection guard), and no new queries are added to logged-out routes.

The two AGENTS.md comment-discipline notes from the prior review have been addressed: the repository comment on applyBylineFilter is now limited to the two invariants a reader needs, and the ContentBylineFilter type docstring no longer contains a justification sentence.

One minor comment-discipline item remains in the new BylineFilter component docstring, which still narrates the rejected exhaustive-list alternative rather than only stating what the component does. Otherwise the code is clean.

[emdashbot]

The byline-filter approach remains sound: it extends the existing server-side content-list filters, matches on translation_group values stored in _emdash_content_bylines, and resolves inferred credits at the list locale so filtering agrees with what the list renders. The query is shaped as a correlated EXISTS from the content table, the IN clause is bounded by schema validation, and the 12 integration tests cover OR matching, no-byline, inferred opt-in/out, locale-scoped inference, status composition, total, and the empty-selection guard. No new queries are added to logged-out routes.

The two comment-discipline items from the last review (applyBylineFilter repository comment and ContentBylineFilter type docstring) are now trimmed to behavior-only statements. One minor AGENTS.md comment-discipline item remains in a docstring the PR edits: a stale GitHub issue reference in FilterBar. That's the only code-level note remaining.

Per the PR description, Discussion #2347 is still unapproved, so merging remains gated on maintainer direction there. Absent that process gate, this is close to an LGTM.

[emdashbot]

This is the right change for the problem described in Discussion #2347 (still pending approval). It extends the admin content list with a server-side byline filter, matches on translation_group values stored in _emdash_content_bylines, and resolves inferred credits at the list locale so filtering agrees with what the list renders. The correlated-EXISTS shape preserves the outer sort index, the 25-id schema cap avoids D1 bind-parameter blow-up, inferred/explicit semantics are handled consistently, and the 12 integration tests cover OR matching, no-byline, inferred opt-in/out, locale-scoped inference, status composition, and totals. No new queries are added to logged-out routes.

I re-read the diff, the full changed files, and relevant call sites/siblings. The previous comment-discipline finding in FilterBar is fixed. One stale GitHub issue reference remains, now in router.tsx directly above the newly-extended filter-state block. That’s the only code-level note. Fix it and this is a code-level LGTM. Merge remains gated on maintainer direction in Discussion #2347, not on the code review.

---

Findings

• [needs fixing] packages/admin/src/router.tsx:352-353

  Comment still references a GitHub issue (#1288) in the filter-state block the PR extends. AGENTS.md says comments are for future readers, not PR/issue references. The FilterBar docstring already dropped this reference; remove it here too.

  	// Filter state. All are part of the query key so changing any of
  	// them restarts the cursor chain from a filtered first page.
  

[MA2153]

Ok I am done with the bot nitpicks.