44c77b26 kept the server's order for sender and subject sorted lists.
That is right for Stalwart 1.0, which sorts lowercased byte-order keys,
but 0.16 compares the raw bytes, capitals first, so on every 0.16
server a sender list read "Adam, Carla, Eve, bea, dave, zed".
- keep the server's order only for accounts that list
`urn:ietf:params:jmap:principals:owner` (every 1.0 account, never
0.16); elsewhere pages and thread groups are re-sorted
case-insensitively, as before 44c77b26
- the client comparator puts a message without a sender or subject
last in both directions, as both versions do
Expanding a thread marked it read in the login's own account instead
of the shared or group account it lives in, so Stalwart answered
notFound or marked an unrelated message with the same id, and since
d7004b38 the thread also stayed unread. The write now names the owning
account. Moving mail between category tabs had the same fault: it took
a listed message's display-only account reference, and now routes each
message like the other keyword writes.
A sender or subject order is collated by the server. Stalwart 1.0 ranks
byte-order sort keys (lowercased name and address, the thread name for
the subject) and puts empty values last in both directions. The client
re-sorted every page and every thread group with `localeCompare` and
empty values first, which turned that order around.
Pages and thread groups whose order has a sender or subject level now
keep the query's order (the Email/get list is put back into the query's
id order). Other orders keep the client-side safety sort, and the
unified view still merges accounts with the client comparator.
Stalwart 1.0 puts `$hasattachment` or `$hasnoattachment` on every
message and derives `hasAttachment` from them alone. It also refuses
keywords over 128 bytes (0.16 cuts them to 128 characters) and more than
100 keywords on one message. The keyword writers ignored Email/set
`notUpdated`, so a refused tag showed until the next reload and then
vanished.
- `markAsRead`, `batchMarkAsRead`, `toggleStar`, `updateEmailKeywords`,
`setKeyword`, `removeKeyword` and `batchUpdateKeywords` check the
Email/set outcome, and the errors carry the JMAP type. Tagging from
the list or the viewer shows "Tagging failed"; a refused category-tab
move rejects the plugin's promise and skips the categorize hooks.
- Tag ids are capped at 121 characters (128 bytes with `$label:`).
- The attachment keywords are hidden in view source, the plugin
projection and the `getKeywords` fallback labels, reserved for
category tabs, and refused by the plugin keyword API. Email/copy and
the cross-server import still carry them over.
- A tag comes off by leaving its key out of the full keyword map instead
of being sent as false, which RFC 8621 does not allow;
`updateEmailKeywords` also drops the false entries local updates leave
behind (`$seen: false` after marking unread).
- The automatic mark-as-read no longer leaves an unhandled rejection
when the server refuses it.
JMAP thread ids are only unique within their account - Stalwart hands out
per-account counters such as "b" - so the cross-account views merged
unrelated conversations that happened to share an id, and every
client-side thread map (expansion, cache, loading flag, counts,
virtualizer key) mixed them up the same way.
Give ThreadGroup an account-scoped `threadKey` derived from the email's
source stamps and key grouping and all thread state by it. `threadId`
stays the raw id for Thread/get, which #281 already routes to the owning
account. fetchThreadEmailCounts now asks each source account for its own
threads instead of one client for every id. Single-account views carry no
stamps, so their key is the bare id and nothing changes there.
Previously tags where very much focused on color coding email and less about
adding additional information. They were also visualized in different ways in
different locations.
This commit gets rid of all "Color-coding" references, aligns visualization of
the tags across the whole project and tries to improve user experience of using
tags in general.
A search box is shown in the tagging control so the user can quickly search for
a tag if they have a huge (more than 10) amount of tags.
Outlook-Web-style pinning: a context-menu Pin/Unpin action stores a
$pinned keyword on the message (plain IMAP-compatible flag, survives
other clients), and pinned mails stay at the top of the folder list
regardless of age, marked with a pin icon.
Ordering is done server-side via the hasKeyword sort comparator
(RFC 8621), applied consistently to the folder fetch, pagination and
the push-refresh so page windows stay stable. The client-side safety
sort in getEmails mirrors it, and sortThreadGroups keeps threads
containing a pinned mail on top so the client-side thread grouping
does not undo the order.
The new-mail notification in refreshCurrentMailbox now checks the
first non-pinned entry: with pinned mails on top, the newest mail is
no longer at index 0 and arrivals would never have notified.
The toggle reuses the color-tag pathway (routed keyword write for
unified views, in-place local patch), then refetches the first page
so the mail floats or sinks immediately. Search and unified views
keep their existing order.
Pin/Unpin strings are added to all 21 locales.
- Updated EmailContextMenu to replace color tag functionality with label tags.
- Modified EmailListItem to display label badges for emails based on keywords.
- Enhanced EmailViewer to include a tag picker for emails.
- Adjusted ThreadListItem to show label badges for email subjects.
- Added tests for email list item and keyword settings to ensure proper functionality of the new tagging system.
- Updated localization files to reflect changes from color tags to labels in multiple languages.
- Introduced a new settings section for managing email keywords (labels/tags) with associated colors.
- Updated email context menu, viewer, and list item components to support the new keyword system.
- Refactored color tag handling to accommodate both new $label: and legacy $color: prefixes.
- Added utility functions for retrieving email color tags based on keywords.
- Enhanced localization files to include translations for the new keyword management features.
- Updated the settings store to manage keyword definitions, including add, update, delete, and reorder functionalities.
- Added tests for the new keyword handling logic.
Linus Rath
lucamzanon
Mathy Vanvoorden
dealerweb
Matthieu MALVACHE