doEmailGet asked the signed-in account for every id, so a message in a
folder shared from another account came back as null even though it was
in the list. A message in the loaded list is now read from the account
that owns it, through resolveEmailBlobContext like attachment downloads.
getAttachment and getRaw keep reading from the signed-in account only.
Fixes#1273
Expanding a conversation in the message list (row click, expand chevron,
or the `x` shortcut) and clicking a row in a Pro folder tab marked the
messages read straight away. They ignored "Mark as read: Never" and any
delay, which the reading pane and the conversation view follow.
Route them through one helper, scheduleAutoMarkAsRead: -1 never marks,
0 marks at once, any other value marks after that many milliseconds and
returns a cancel function.
- New store action autoMarkExpandedThreadAsRead keeps one pending timer
per thread key. Collapsing the thread, or collapsing all threads, drops
it. Both expansion paths (EmailList and the `x` handler in MailApp) use
it.
- MailApp's handleEmailSelect drops the pending mark of every expanded
thread other than the one the newly opened message belongs to, through
cancelAutoMarkThreadAsRead. Moving on with `j`/`k` or a click no longer
lets the delayed mark land on a conversation the user has left. The
thread stays expanded.
- ProFolderTabBody schedules the row mark through the helper and drops a
pending one when another row is opened or the tab unmounts.
With several accounts connected, the composer treated every account's
identities as "own" when deciding whether a message was self-sent (#703).
A message that account B sent to account A therefore looked self-sent
when replying from A, so the reply was addressed to the original To -
account A itself - and From was switched to B.
Self-sent now means "sent by the account holding the original":
buildReplyRecipients takes an optional selfSentEmails list (defaulting to
ownEmails, so single-account behaviour is unchanged), and the composer
passes the source account's identities there and to the From selection.
Reply-all still drops every connected account's addresses.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The task modal and the plugin API send an all-day due as a bare date
("2026-10-14"). A task's due and start are LocalDateTimes (RFC 8984).
Stalwart accepts the bare date and echoes it back over JMAP, but the
stored iCalendar has no DUE, so CalDAV clients (phones, Thunderbird)
show the task without a date. "2026-10-14T00:00:00" with showWithoutTime
is stored as DUE;VALUE=DATE.
createCalendarTask and updateCalendarTask now complete a bare due or
start to midnight. Every write goes through them, so a task saved by an
older client gets a proper due when it moves to another account.
Tests: create, update and the cross-account move against round trips
recorded on Stalwart v0.16.24 (JMAP set, then CalDAV GET of the stored
iCalendar); times and a cleared due stay as they are.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Complete Estonian translation (every key in en), wired into the locale list, the message loaders, the language switcher (with an Estonian flag drawn in the Twemoji style, since Twemoji's set is not used for it) and the locale-count test.
Co-Authored-By: Claude Sonnet 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
Part 2 of 3 of the account archive agreed in #1198. When the admin turns on
"Account List Backup: Passwords" (off by default), saving the list offers to
include the passwords of the accounts signed in here with a plain password.
They are encrypted in the browser together with the list. On restore, those
accounts are signed in to in the background, one by one, without leaving the
active account; a refused password leaves the account waiting for a sign-in by
hand, as before. OAuth and TOTP accounts are saved without a password.
Calendars were listed in the order the server returns them, which for
Stalwart is creation order, and the sortOrder property was never read.
Follow the JMAP Calendars rule instead: lower sortOrder first, equal
sortOrder by name (case- and accent-insensitive, numbers by value). The
store keeps the list sorted, so the sidebar, the calendar pickers and the
settings all show the same order; each account's calendars stay together.
Calendar settings gain move up / move down buttons, visible on touch
screens too, and drag and drop for the user's own calendars. A move
renumbers that account's calendars 1, 2, 3... and writes sortOrder only
where it changes. The renumbering also covers the account's calendars the
settings list does not show (iCal subscriptions), so they keep their
place relative to the others. Shared calendars are not offered for
reordering, their order is the owner's.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Linus Rath
Linus Rath
Ali Yousuf
Peterka35
Viktor Shulika MacBook Air M5andClaude Opus 5.5
balabommablock-cpu
Sebastian SanitzandClaude Opus 5.5
raudraidoandClaude Sonnet 5.5
Tobias Genannt
lucamzanon
lucletoffeandClaude Opus 5.5