mirror of
https://github.com/bulwarkmail/webmail.git
synced 2026-10-31 00:12:39 +00:00
Patrick RotterandClaude Opus 5
3560cf258b
Tags, pins and $answered/$forwarded/$mdnsent set on a message in a shared/group mailbox opened directly from the "Shared" sidebar section did not persist: they showed until the next reload and were then gone. The call sites resolved the target account as `isUnifiedView ? email.sourceAccountId : undefined`. Outside the unified view that is always `undefined`, so the write went to the reaching client's own account, which the server answers with `notUpdated` / `updated: null` and no error - the same silent no-op that `email-store-shared-folder-actions.test.ts` already covers for the batch actions. Emails fetched from a shared folder this way are undecorated (no `sourceAccountId`); the owner is only recoverable from the selected mailbox. `toggleStar` never had the bug because it routes through `resolveEmailActionContext`, which resolves the owner from the email's source in an aggregate view and from the selected mailbox otherwise. That resolver was reimplemented inline at each keyword call site, and the inline copies only ever covered the aggregate half - so starring a shared message persisted while tagging the same message did not. Move the two keyword writes into store actions built on that resolver and route every call site through them, including the read-receipt and Pro-compose paths that previously passed no accountId at all. The store actions resolve only for an email the store actually knows. A Pro tab fetches its own email and never enters `emails` or `selectedEmail`; for those the selected mailbox says nothing about the message's owner, so guessing from it would send an own-account write to a shared account whenever a shared folder happened to be open. An unknown email keeps the previous behaviour instead. Behaviour on own-account and unified-view messages is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>