Add a Changelog page that renders CHANGELOG.md from the header menu,
switch the default color theme to the brand-accurate Stalwart theme, and
document all changes since v1.1.1.
Plain links (not wrapped in a collapsible) are siblings of collapsible
groups within the same AccordionLevel, but their onClick never touched
that level's openId — so a group left expanded stayed expanded even
after navigating to an unrelated top-level page, or to a sibling link
outside any group.
Both SidebarTopItem and SidebarSubItem's link branches now read the
AccordionLevelContext they're rendered in and call setOpenId(null)
before navigating. For a link inside its own group, this is
immediately overridden by AccordionCollapsible's existing
containsActive effect (which reopens the branch that now contains the
active page), so nested navigation is unaffected — only a truly
unrelated group gets collapsed.
Verified: opening Directory (showing Groups), then clicking Cluster (a
plain top-level link) now collapses Directory instead of leaving it
expanded.
The color theme previously named "Stalwart" was actually just the
neutral black/white default — it never used Stalwart's own brand
color. Renamed it to "Default" (ColorTheme 'stalwart' -> 'default'
value; label/i18n key updated) and added a genuinely new "Stalwart"
theme in its place.
Colors sourced directly from the official site's own design tokens
(D:\project\stalwart_website/src/styles/tokens.css): brand red/pink
#db2d54 (light primary/ring) and #ff4570 (--brand-hi, dark
primary/ring), converted to oklch via the sRGB->OKLab->OKLCH matrix
transform to match this project's existing token format. Neutrals use
near-true-gray values (also converted from the site's actual light/
dark backgrounds and text colors) rather than being re-hued toward the
brand color like the other theme presets — matching how the real site
treats color (saturated only on the accent, neutral everywhere else).
Verified in the running dev server: Default reverts to the original
neutral look, Stalwart renders the brand red across primary buttons,
active nav state, checkboxes, and badges in both light and dark mode.
No regression (243 tests, typecheck, lint all pass).
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.
New scripts/dev-seed.sh (+ .ps1), run after dev-server-init: seeds the
test server with Users (alice, bob, carol — spanning User/Admin roles,
group membership, an alias), Groups (engineering, marketing), Mailing
Lists (newsletter, support), and custom Roles (Support Agent,
Read-only Auditor), so each admin panel screen has real data to test
against instead of an empty list.
Idempotent (skips if 'alice' already exists), documented as workflow
step 3 in DEVELOPMENT.md (renumbering the steps after it) and listed
in AGENTS.md. Verified end-to-end with both scripts against a fresh
server, including idempotency and the resulting UI (Accounts, Groups,
Mailing Lists, Roles all populated as expected).
Preview/dev tooling that assigns a free port via $PORT (because the
project's usual 5173 is taken) had no way to make Vite actually bind
there — Vite ignores PORT by default and falls back to its own
auto-increment, so the dev server would come up on a different port
than the one the tooling proxied to.
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.
Verified against a live server: x:Account/query rejects sort on every
property tried, including real ones like emailAddress, with
unsupportedSort — the schema's empty list.sort is accurate, this is a
systemic server gap, not something specific to this fork's synthetic
columns.
Added client-side sorting (SCHEMA-DEVIATION: account-client-sort) for
Email Address, Full Name, Usage/Quota, and Aliases on both lists,
reusing the fetch-all-then-sort-locally mechanism already established
for mailbox-client-hierarchy-sort: clicking a sortable header switches
that one query to an unpaginated fetch, sorts the results in memory by
the appropriate accessor (numeric for Usage/Aliases, string compare
otherwise), then paginates client-side. Role isn't included (not a
sortable scalar). Normal server-paginated lists are unaffected — this
only activates when a client-sortable column is actually clicked.
Verified end-to-end: sort indicators appear only on the intended
columns, clicking Email Address/Aliases correctly reorders rows and
toggles ascending/descending, Groups behaves the same as Accounts.
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.
Pre-existing dead code (defined, never imported anywhere) that also
tripped react-refresh/only-export-components since it mixed a
non-component export into a component-only file — eslint treats that
as an error, which was silently failing every CI run's lint step
(including this release build) well before this session's changes.
This fork's favicon.ico had drifted from upstream's: same Stalwart logo
and color (#DB2D54) in both, but the fork's version had visible padding
around the logo (trimmed bounding box 120x104 within the 128x128 icon)
while upstream's fills the full canvas edge-to-edge. Also encoded at a
lower bit depth (8-bit indexed vs upstream's 32-bit true color).
Replaced with the exact file from stalwartlabs/webui (md5 e9f5eaa1...,
matches byte-for-byte) rather than re-exporting, so it can't drift
again the same way.
The "Active WebUI" card (Settings > Web Applications) only showed
description and __APP_VERSION__, never the resourceUrl it's actually
built from — add it as a linked "Source" row.
That card also turned out to be misleading in local dev: it reads the
x:Application record whose urlPrefix matches /admin or /account, and a
freshly bootstrapped server keeps Stalwart's seeded default there
("Stalwart Web Interface", pointing at stalwartlabs/webui's release),
regardless of what's actually being served — in dev that's this fork,
served directly by Vite, which never touches that record at all.
dev-server-init.sh/.ps1 now point that record's description and
resourceUrl at this fork's own release, so the card (now including the
visible Source URL) reflects what's actually running instead of
Stalwart's factory default.
Verified end-to-end against a fresh container with both scripts.
Tapping Management/Settings/Account in the sidebar footer navigated to
that section's default page, which triggered the same effect that
closes the sidebar after picking a leaf page on mobile — so the
sidebar snapped shut right after switching sections, forcing users to
reopen it just to browse the new section's pages.
Have handleSectionClick flag the navigation as section-only via a ref;
the mobile auto-close effect consumes that flag and skips closing for
that one navigation, leaving normal leaf-page navigation unaffected.
Verified on a mobile viewport: switching sections now keeps the
sidebar open, while picking a specific page still closes it as before.
Add a Troubleshooting section to DEVELOPMENT.md covering the case that
just happened: npm run dev only reads .env.development.local at
startup, so regenerating a token or restarting the Docker container
while it's already running silently leaves the UI unable to reach the
backend until it's restarted.
README.md's "one command" claim for spinning up the test server was
stale since dev-server-init.sh became a separate one-time step.
Requested: dev-token.sh/.ps1 tokens should last 3h by default, with an
argument to override the duration.
Server-verified finding: STALWART_RECOVERY_ADMIN (the break-glass
account docker-compose.yml and the scripts used) always issues OAuth
tokens with a fixed 1h expiry, regardless of the server's configured
accessTokenExpiry — confirmed against the live container, including
after changing the setting and restarting. Confirmed x:ApiKey objects,
by contrast, support an arbitrary expiresAt set per request, and their
secret works directly as a bearer token.
Add scripts/dev-server-init.sh (+ .ps1): a one-time, idempotent setup
step that completes the server's bootstrap wizard (default domain, no
TLS certificate request), creates a real "devadmin" admin account, and
sets the server's default OAuth token lifetime to 3h.
Rework dev-token.sh/.ps1 to authenticate as devadmin and create an
x:ApiKey with a caller-supplied expiry (`dev-token.sh 1800` for 30
minutes, defaults to 10800s/3h) instead of running the OAuth PKCE flow
against the recovery account. Verified end-to-end against a fresh
container, including a real browser session against the running WebUI.
Also includes an incidental package-lock.json sync (was still pinned to
v1.0.8 / stale dependency ranges from before the upstream merge).
Add docker-compose.yml: a disposable Stalwart instance with a fixed dev
admin account (STALWART_RECOVERY_ADMIN), matching the credentials
scripts/dev-token.ps1 already expected. Wired up via new npm scripts
(dev:server, dev:server:down, dev:server:logs).
scripts/dev-token.ps1 was previously untracked (the whole scripts/
directory was gitignored) even though it's part of the documented dev
workflow — un-ignored it, and added scripts/dev-token.sh, a POSIX
equivalent for non-Windows shells and AI agents without PowerShell.
New DEVELOPMENT.md documents the full loop end-to-end (start server,
get a token, run the dev server, verify), written so it's actionable by
both humans and AI coding agents without needing a browser. Linked from
AGENTS.md (Commands) and README.md (Getting started).
Verified manually: docker compose up brings the server to a healthy
state, /api/auth + /auth/token issue a working bearer token, and
/jmap/session returns 200 with it end-to-end.
Rewrite everything below the project header to actually describe this
fork instead of a generic copy of upstream's README:
- "About this fork" + list of official Stalwart repositories.
- Corrected the "Nothing is hardcoded" overclaim; Features now lists
what's shared with upstream vs. this fork's own additions, and links
to SCHEMA_DEVIATIONS.md for the tracked exceptions.
- New "Switching your server to this fork's UI" section: how to point
a Stalwart server's WEBAPP application at this fork's release build
via stalwart-cli, and how to switch back.
- Support section now distinguishes fork-specific issues (this repo)
from Stalwart Mail Server support (upstream channels).
- License/Copyright text left untouched; added one line noting fork
changes stay under the same dual license per each file's SPDX header.
The project header block (logo, title, badges) is unchanged.
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.
Any AI agent working in this repo (Claude Code, Codex, Kimi, or any
other) must stay schema-driven and never hardcode object types, field
names, filters, or columns as a shortcut. AGENTS.md is the index (tech
stack, commands, universal rules); CLAUDE.md just points Claude Code at
it so the same rules apply without duplicating content. The detailed
schema-fidelity rule lives in .agents/rules/.
.gitignore previously excluded *.md except README/CHANGELOG, which
would have hidden these files (and SCHEMA_DEVIATIONS.md) from git.
main.tsx no longer needs an eager logo fetch call: Logo.tsx already
triggers ensureLogoLoaded() from logoCache.ts (the fork's own
implementation, kept over upstream's during the sync merge).
Documents everything since the v1.0.8 entry: icon batches, the Web
Applications active-app info card, PWA support, Log Entries filters
and refresh button, Accounts list columns, the account-switch fixes
(reviewed against and aligned with upstream's own fix for the same
issue), the WebUI Fork rename, mailbox hierarchy, new color themes,
and the confirmed-backend-only limitations (Log filter properties,
exact-match-only text search across the admin API).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Aligns with upstream stalwartlabs/webui@189e270 (v1.0.7, "fixes #17"),
reviewed after they independently landed a fix for the same issue:
- authStore now persists activeAccountId (sessionStorage) and
setSession preserves it across a session refresh instead of always
resetting to primaryAccountId, so a hard reload keeps you on the
group account you had selected instead of bouncing back to your own.
- switchAccount now clears cacheStore (displayNames/objectLists) when
actually changing account, since those were resolved against the
previous account and would otherwise show stale labels.
- The ErrorBoundary wrapping MainContent is now keyed on
activeAccountId, forcing a full remount of every view on switch.
This is more robust than gating individual components' fetch
effects on activeAccountId (our earlier fix in DynamicList.tsx,
kept as-is — harmless now, but no longer load-bearing on its own)
since it covers every current and future view type, not just lists.
Verified against a live instance: switching to a group account updates
the JMAP accountId immediately (no tab switch needed), and a full page
reload keeps the group account active instead of resetting to admin.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds three new color themes alongside the existing Stalwart/Ocean/
Forest/Violet set so more people can find one they like, and switches
the out-of-the-box defaults to Ocean + square corners instead of the
neutral Stalwart theme + rounded corners (existing users' saved
preferences are untouched, this only changes what a fresh install
starts with).
Verified in the browser: all three new themes render with legible
primary-foreground contrast in both light and dark mode, and the
pre-hydration flash-prevention script in main.tsx (which reads
localStorage before React mounts) now recognizes the new theme names.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fixesstalwartlabs/webui#16. Mailboxes had no visual indication of
parent/child relationships. Since a mailbox's parent can land on a
different server page than the mailbox itself, the Mailbox list now
always fetches the full set (like the existing client-filter path)
and orders it depth-first by parentId, then indents each row's name
with a corner connector proportional to its depth.
Verified against a live instance with a 3-level nested hierarchy
(Projects > Alpha > Docs) alongside the default flat mailboxes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Switching accounts via the profile dropdown (TopBar) only updates
authStore.activeAccountId with no navigation, but DynamicList's fetch
effect depended on [viewName, sort, resolved?.list, appliedFilters] —
missing activeAccountId, and account resolution only happened through
a non-reactive getState() snapshot inside getAccountId(). So views
like Mailboxes, Calendars, or Sieve Scripts kept showing the previous
account's data until an unrelated viewName change (switching tabs)
incidentally re-ran the effect.
Reproduced and verified against a live Stalwart instance: a mailbox
list stayed on accountId "b" after switching to a group account "d"
in the dropdown, and only picked up "d" after navigating away and
back. Subscribing to activeAccountId reactively and adding it to the
effect's dependencies fixes the switch to apply immediately.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Adds a Refresh button next to Filters, right-aligned, specific to the
Logs list. Guarded to one click per 5 seconds (button disabled and
re-enabled via a timer) to avoid hammering the server if left clicked
repeatedly.
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>
Adds vite-plugin-pwa with a generated manifest, icon set derived from
the Stalwart mark (192/512/maskable/apple-touch), and theme-color meta
tags. /api and /jmap are excluded from the service worker's navigate
fallback and are never precached or runtime-cached, so authenticated
mail data can't end up in Cache Storage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Steven RYDELL