Mailing Lists, Roles, and Domains got new/existing columns in prior
commits but no way to sort them — the account-client-sort mechanism
was only wired up in accountColumns.ts. Extracted its one-line
clientSortable() column tagger into schemaDeviationTypes.ts (shared,
same intersection-type pattern) and used it in all four column-patch
files:
- Mailing Lists: Email Address, Description, Aliases
- Roles: Description, Enabled Permissions, Disabled Permissions
- Domains: Domain Name, Enabled, Aliases
Re-verified server sort support live, per list this time rather than
just Accounts: every property tried returns unsupportedSort except one
surprise — x:Domain/query actually accepts sort by "name", despite the
schema not declaring it. Documented in SCHEMA_DEVIATIONS.md and
deliberately routed through the same client-sort path as everything
else instead of adding a one-off "trust an undeclared sort" mechanism
for that single case.
Verified in the running dev server: sort indicators appear on the
intended columns for all three lists, clicking reorders rows correctly
(alphabetical on Mailing Lists' Email Address, numeric on Roles'
Enabled Permissions: 1 -> 3 -> 50 -> 229 -> 244 -> 452), Domains sorts
without error. No regression on Accounts/Groups.
Same account-alias-count-column deviation already used on Accounts,
Groups, and Mailing Lists, extended to x:Domain: adds a synthetic
aliasCount column resolved from the real aliases property (a `set` of
alias domain names here, vs. an objectList elsewhere — same id-keyed
wire format, so the existing generic COUNT_COLUMN_SOURCES handling
needed no changes).
Verified in the running dev server: the column renders correctly
alongside the domain's existing Enabled/Certificate/DNS columns.
New SCHEMA-DEVIATION: role-permission-count-columns — the Roles list
only shows Description, so seeing how broad or restrictive a role is
required opening it and counting permissions by hand.
Generalized DynamicList's existing alias-count handling (previously
hardcoded to the single `aliasCount` -> `aliases` mapping) into
COUNT_COLUMN_SOURCES, a table of synthetic "*Count" column names to the
real set/objectList property they count. account-alias-count-column
now runs through the same generic path with no behavior change;
role-permission-count-columns (enabledPermissionCount/
disabledPermissionCount -> enabledPermissions/disabledPermissions) is
the second consumer, added with zero new DynamicList.tsx branching.
Verified against the live dev server: correct counts for both seeded
custom roles (Support Agent: 3/0, Read-only Auditor: 1/0) and the
built-in roles (System Administrator: 452/0, User: 244/0, etc.).
Confirmed no regression on Accounts' existing Aliases column/sort.
Same account-alias-count-column deviation already used on Accounts and
Groups, extended to x:MailingList: adds a synthetic aliasCount column
and lets DynamicList's existing generic column-name-driven handling
resolve/render it — no changes needed there, the mechanism was already
list-agnostic.
Verified in the running dev server: the column renders 0 with no
aliases set on either seeded mailing list.
Previous commit hardcoded which lists (viewName === 'x:Account/User' /
'x:Account/Group') and columns (a fixed accessor map) got client-side
sort. Moved the "which columns" decision into the schema itself instead:
- New ClientSortableColumn type in schemaDeviationTypes.ts (intersection
with the official Column type, same pattern as ClientOnlyFilterEnum —
src/types/schema.ts stays untouched).
- withAccountListColumns tags Email Address, Full Name, quotaUsage, and
aliasCount with clientSortable: true when it builds the Accounts/
Groups column lists — the deviation-specific knowledge lives where the
columns themselves are defined.
- DynamicList reads that flag generically (clientSortableColumns, a
useMemo over resolved.list.columns) with no viewName check at all.
getClientSortValue() replaces the old per-list accessor map: real
columns compare their own property directly, only the two synthetic
columns need a value override.
Net effect for Accounts/Groups is unchanged (verified: sort indicators
still only on Email/Full Name/Usage/Aliases, ascending/descending still
works). Any other list can now opt into the same client-sort mechanism
by tagging a column clientSortable, without touching DynamicList.tsx.
Same pattern as the existing quotaUsage deviation: neither list's
schema exposes an alias count as a column, only the full `aliases`
objectList on the detail view. Added a synthetic `aliasCount` column
(SCHEMA-DEVIATION: account-alias-count-column, documented in
SCHEMA_DEVIATIONS.md) that DynamicList resolves by fetching the real
`aliases` property and counting its entries.
Verified against a live test server: adding a real alias to an
account correctly bumps its Aliases count from 0 to 1 in the list.
Groups have real usedDiskQuota/quotas fields, same as Users, but the
Groups list schema doesn't expose usage as a column any more than the
Accounts list did — extend the existing account-quota-usage-column
deviation to x:Account/Group too (SCHEMA_DEVIATIONS.md updated).
The isAccountsList gate that resolved/rendered quotaUsage was hardcoded
to viewName === 'x:Account/User', so it silently no-oped for Groups.
Replaced with hasQuotaUsageColumn, derived from whether the resolved
list's own columns include the synthetic quotaUsage column — works for
any list withAccountListColumns patches, not just a hardcoded pair of
view names.
Also: "Unlimited" (no quota configured) now renders as "∞" instead of
the word, matching the size formatting style used elsewhere in the
column.
src/types/schema.ts had drifted from the official schema contract: a
`clientOnly` field had been added to `FilterEnum` to support client-side
log filtering. Restored it to match upstream exactly and moved the
deviation-only type into a new intersection type in
src/lib/schemaDeviationTypes.ts instead.
Audited the codebase for every place the UI does something the official
schema doesn't support and tagged each with `// SCHEMA-DEVIATION: <id>`,
documented in the new SCHEMA_DEVIATIONS.md registry (what, why, and the
ideal server-side fix):
- log-client-filters: Level/Event filters on Log Entries, applied
client-side because x:Log/query rejects them as JMAP filters.
- account-quota-usage-column: synthetic quotaUsage column on the
Accounts list.
- mailbox-client-hierarchy-sort: full-fetch + client-side sort to
reconstruct mailbox parent/child hierarchy.
- webapp-enabled-column-fallback: synthetic "Enabled" column label for
x:Application when the schema list doesn't define one.
Other viewName/objectName special cases (x:OtpAuth, x:Expression,
x:Rate, x:Action, x:Trace, CustomComponent/*) were checked against
upstream and are pre-existing architecture, not fork deviations.
Created At is replaced with two columns that previously required
opening each account individually: Role (badge, resolved against
x:UserRoles specifically since the list's merged User/Group field
definitions otherwise resolve `roles` against the wrong object) and
Usage / Quota (usedDiskQuota vs quotas.maxDiskQuota, "Unlimited" when
no limit is set).
Also makes renderCellValue's generic 'object' case resolve variant
labels via schema.schemas, instead of only ever printing the raw
@type string.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The backend rejects `level`/`event` as x:Log/query filter conditions
(unsupportedFilter), even though both are already returned per row.
Since a real fix requires backend changes outside this repo, the two
filters are injected into the schema client-side (clientOnly flag) and
applied entirely in the browser: excluded from the JMAP filter sent to
the server, and used to narrow an eagerly-fetched, locally-paginated
result set instead.
Also makes large enum filters (Event has 634 values) render as a
searchable Combobox instead of a plain Select, generically for any
list with more than 15 enum options.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Steven RYDELL