api.tasks.create and update take links by id (an http(s) URL, a mailto:
address or a path of this Bulwark, stored as its full URL; at most ten)
and relatedTo (by a mail's Message-ID or another object's UID, with its
relation types; at most ten). They merge on update as alerts do: an
entry given is set, one given null is removed, and entries the plugin did
not name, such as an attachment's link another app wrote, stay as the
server holds them.
TaskView returns both as any app wrote them. Lengths, ids and URL
schemes are checked as the rest of the calendar API checks them. Task
reads now ask the server for links too.
api.tasks.create and update take alerts by id: a trigger from the task's
due (or start) as an ISO 8601 duration, or at an instant in UTC; display
or email; at most five. An update merges by id, each alert written by its
JMAP patch path: an alert given is set, one given null is removed, and
alerts the plugin did not name, such as one another app wrote, stay as
the server holds them; null for the whole map removes every alert.
Whether the map is patched or written whole is decided on the task as the
server holds it, not an older copy. An alert kept with the same trigger
and action stays acknowledged, so a snooze is an update of its trigger,
which then fires again. While a task uses its calendar's default alerts,
a change makes them the task's own under new ids, as the task form does,
an alert under a default's id is refused rather than dropped, and
removing every alert turns the defaults off too.
TaskView returns the alerts, each with when it was acknowledged, and
useDefaultAlerts. api.tasks.acknowledgeAlert dismisses one alert (or
undoes that with null) by writing only its acknowledged. A plugin's
writes to one task go one after another, since Stalwart refuses a set
while another is under way on the same object. The task store applies
patch paths to the task the caller read, so a task the list does not
hold is shown and reported whole.
A plugin opens a message as a click on a list row or on a search result
entry naming one does, also a message of a shared or group account,
reached through the login that reads it. On the mail page it opens in
place, in the Pro shell in an email tab as a message link does there;
elsewhere the tab loads the message's link, at most five times a minute.
A message no login reads, or one its account does not have, is refused
with an error the plugin sees, as is one the mail page could not open.
Needs email:read.
Input inside an iframe never reaches the host window, so the idle timeout
signed users out while they worked in a plugin page, dialog or panel. The
sandbox runtime now reports trusted input in its frame (the guard's own
events, focus left out) through a MessagePort it hands the host with
sandbox-ready, before any plugin code runs, at most once per 15 s. The
host bridge passes it to a small notifier the session timeout guard
counts like its own window's input, so it reaches the other tabs too.
- `directory:read` for api.user.findPeople, with at least 3 characters,
at most 20 ids, 20 results and 10 lookups a minute, in the directory
of the account the call names; one load in flight per client.
- Plugins hear `group` only for accounts the server confirmed are group
principals; the policy's fallback stays for the admin's scopes.
- The email.* keyword methods refuse $draft, $junk, $notjunk and
$phishing.
- A plugin keeps at most 4 KB in a mailbox and reads it 30 times a
minute; the email:write consent text says others in a team mailbox
can read it.
- email.updateKeywords also changes the rows of expanded conversations.
What the team inbox plugin needs, kept general for other plugins:
- `api.ui.setListFilters`: keyword filters drawn as chips in the list
header of the folders they apply to (by account kind and folder
role). A chip the user turns on is ANDed into the folder's query and
comes off with one click; a keyword change a filter tests loads the
list again (ui:message-list).
- Actions get `accounts`, `hasKeyword` and `notKeyword`, so a button
shows only on messages of group accounts, or of a keyword state; the
click of message-row-actions and reader-actions carries the message's
`accountId`.
- `api.email.updateKeywords`: several keywords in one change, through
the list for a listed message (email:write).
- `api.user.getSelf`, `getMailAccounts` and `findPeople`: the user's own
account id (Stalwart's principal id), which accounts are group
accounts, and people from the directory (account:read).
- `api.accountData`: a plugin's own entry in a mail account's shared
Inbox metadata on Stalwart 1.0 (email:read / email:write).
- Row badges take an `icon`.
Every plugin iframe loaded /plugin-sandbox, a force-dynamic Next page.
Each frame then fetched, parsed and hydrated Next's client router on top
of React and the runtime, and the server rendered the page once per
frame, one after another when a dozen plugins started together.
Sandboxed frames have opaque origins, so the browser's code cache never
helps, and they run on the host page's main thread: with 12 plugins
the frames took 2.5-3 s to come up after the app had loaded.
The sandbox routes now return a small HTML page with the UI kit's
stylesheet and the runtime as an ES module, both built ahead of time:
- `scripts/build-plugin-sandbox.mjs` bundles the runtime with esbuild
and compiles `plugin-kit.css` with the app's Tailwind setup into
`public/plugin-sandbox-assets/`, with a manifest. Named Tabler imports
are pointed at the icons' own files, so the full icon set stays in a
chunk that only loads for an icon name the kit doesn't ship.
- `npm run build`, `npm run dev`, the Dockerfile and the perf-guard
workflow run it before `next build`.
- `lib/plugin-sandbox/sandbox-document.ts` writes the page; proxy.ts
still sets the sandbox CSP and the script carries its nonce.
- The assets are served from public/ with CORS and immutable caching.
A frame on an idle page is ready in 255 ms instead of 362 ms, eleven at
once in 1.0 s instead of 2.1 s.
Plugins running in iframe sandboxes previously lacked access to the user's regional formatting settings (dateLocale, timeFormat 12h/24h, timeZone, and firstDayOfWeek) unless they requested privileged settings:read permissions.
This mirrors the host's resolved presentation preferences into the plugin sandbox:
- Adds RegionalSnapshot (locale, dateLocale, hour12, timeZone, firstDayOfWeek) to BackgroundInit, SlotInit, and LocaleChangeMsg.
- Implements snapshotRegionalSettings() in host-bridge, reusing host resolveDateLocale() and getEffectiveTimeZone().
- Subscribes stores/plugin-store.ts to useSettingsStore to broadcast updates to running sandboxes when regional preferences change.
- Exposes api.i18n.formatTime(date, options) and api.i18n.formatDate(date, options) along with regional getters on api.i18n.
keywords.add now records the plugin on each definition it adds
(addedBy). keywords.update changes the label, colour or visibility of
those definitions, never their id; keywords.remove deletes them, as
Settings > Tags does, and leaves the keywords on messages alone. Both
need settings:write and skip every other definition, so a plugin cannot
rename or delete the user's own tags or another plugin's.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Add Combobox component supporting single and multiselect modes, search filtering, and clear button
- Implement floating dropdown bridge and host slot portal so dropdown renders cleanly outside plugin iframe
- Fix clear button and chip removals to not unexpectedly open the dropdown
- Add comprehensive unit tests covering Combobox options, clear behavior, multiselect, and bridge communication
Linus Rath
Jacob Zeitz
Linus Rath
Tobias Genannt
