Calendar: write shared events in the account that holds them

jcoffey-dev commented

2026-10-09 22:34:22 +00:00

Owner

Fixes #49. Thanks @dwofford for such a clear report.

Events in a shared calendar were being written to your own account, so edits and deletes either failed or hit your own event with the same id. They now go to the owner's account, and you can create events in a calendar that's been shared with you for writing.

inbuxa-webmail gets the same fix in inbuxa/inbuxa-webmail#61.

Fixes #49. Thanks @dwofford for such a clear report. Events in a shared calendar were being written to your own account, so edits and deletes either failed or hit your own event with the same id. They now go to the owner's account, and you can create events in a calendar that's been shared with you for writing. inbuxa-webmail gets the same fix in inbuxa/inbuxa-webmail#61.

jcoffey-dev added 1 commit 2026-10-09 22:34:22 +00:00

Calendar: write shared events in the account that holds them

ci / node (pull_request) Skipped

Details

ci / version (pull_request) Skipped

Details

ci / docker-build (pull_request) Skipped

Details

ci / publish (pull_request) Skipped

Details

github/ci (branch) GitHub Actions

Details

ci / github (pull_request) Successful in 2m3s

Details

4b0a3dca6c

Edit, delete, a reply and a single date of a shared series were all sent
to the reader's own account under the owner's event id (#49). Ids only
mean something inside their account and Stalwart's are short, so that
was notFound at best and at worst changed or deleted the reader's own,
unrelated event of the same id. New events couldn't go into a shared
calendar at all, even with write rights.

- An instance from a shared calendar carries its account, and is keyed
  by it, so it no longer shares a key with one of the reader's own
- getEvent, createEvent, updateEvent, destroyEvent and rsvp take that
  account (default: the reader's own); the occurrence lookup runs there
  too, and a shared delete clears the shared copy, not the reader's
- The popover, drag-to-move, the context menu (duplicate included) and
  the editor pass it through
- The editor offers shared calendars the reader may write to, named
  with whose they are; an existing event keeps to its own account,
  since JMAP has no moving an event between accounts

Fixes #49

jcoffey-dev referenced this issue from a commit

2026-10-09 22:35:12 +00:00

Calendar: write shared events in the account that holds them

jcoffey-dev referenced this pull request from inbuxa/inbuxa-webmail

2026-10-09 22:35:17 +00:00

Calendar: write shared events in the account that holds them #61

jcoffey-dev commented

2026-10-09 22:41:50 +00:00

Author

Owner

Tested this with two real accounts sharing a calendar, both with an event using the same id. Deleting the shared event from Bob's side now removes Alice's and leaves Bob's alone, and new events can go into the shared calendar too.

jcoffey-dev merged commit 6de996101c into main

2026-10-09 22:53:19 +00:00

jcoffey-dev deleted branch fix/shared-calendar-writes

2026-10-09 22:53:19 +00:00

jcoffey-dev referenced this pull request

2026-10-09 22:53:37 +00:00

Edit/Delete on an event in a shared (writable) calendar is sent to the reader's own account; can't create events in a shared calendar #49

Calendar: write shared events in the account that holds them #50