mirror of
https://github.com/bulwarkmail/webmail.git
synced 2026-11-04 08:15:41 +00:00
Linus Rath
fd30fdcd27
The AI assistant's "more actions" need host calls today's plugin API lacks. Area c of lib/plugin-sandbox/assistant adds them: - `calendar.respond(emailId, status)`, new permission calendar:respond: answers an invitation of the user's own account through lib/calendar-rsvp.ts, like the reader's banner - `calendar.deleteEvent` now returns an undo token for a single event; `calendar.undoDelete` creates it again from the host's copy - `filters.list/create/undo` over Settings > Filters' model; forward, redirect, reject, discard and keep are refused, and so are folders that are shared or not the account's own - `email.batch/undoBatch`: up to 200 messages through the store's batch functions, restore points first, one entry in the undo history - `vacation.get` also says whether the out-of-office forwards mail - `app.describeSettings`, `app.setSettings` and `app.undoSettings`, new permission settings:change, over the allow-list in lib/settings-schema.ts, refusing locked, hidden, restricted and gated settings when the change is made Undo tokens stay in the host for 30 minutes, bound to the plugin and the account. app.getSettings now shows every setting setSettings may change. settings:write's text is reworded to what it gates (tags). plugin-host-api-app-info gains a test; its other assertions are as they were.
Host APIs for the AI assistant (2.2)
Host calls the assistant plugin needs, one set of files per area, so the areas can be built side by side without editing the same lines:
| Area | What | Files |
|---|---|---|
| b | More context: attachment text and images, threads, the list selection | b.types.ts, b.ts, b.runtime.ts |
| c | More actions: invitations, filters, batches, out-of-office, settings | c.types.ts, c.ts, c.runtime.ts |
| d | Files: find, read, attach, save, create | d.types.ts, d.ts, d.runtime.ts |
| f | The panel in every view | f.types.ts, f.ts, f.runtime.ts |
Each area fills its own three files:
<area>.types.ts(pure, no imports from the app):PERMISSIONS, the permissions the area adds (they joinALL_PERMISSIONS), and<Area>HostFeatures, the flags it adds toapi.host.features.<area>.ts(host side):PERMS(method → permission, joinsPERM_PER_METHOD),dispatch(plugin, method, args)(returnsNOT_MINEfor methods it doesn't own) andfeatures()(its flags right now).<area>.runtime.ts(inside the sandbox):runtime(callApi), the methods it adds to the plugin'sapi, by namespace ({ email: { getThread } }).
index.ts, runtime.ts and types.ts merge the areas; host-api.ts,
host-features.ts, runtime.tsx and plugin-types.ts read only those. A new
permission needs a check (a method in PERMS, a slot or a hook), its texts
in every locale under plugins.permissions.<key>, and docs.