Changing one occurrence drops everything you didn’t change
Expected Behavior
only the changed field is different; the title, location, guests and reminders stay.
Actual Behavior
the occurrence has no title, location, guests or reminders.
Reproduction Steps
1 Create a weekly event with a title and a location.
2 Through JMAP, change just one occurrence, e.g. only its start time or its description.
3 Look at that occurrence over CalDAV or JMAP.
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
in calcard src/jscalendar/export/convert.rs (around line 1963), each changed occurrence is written using only the fields that changed. The rest of the event isn’t copied in first, so everything else is lost.
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
Thanks for the detailed report and for pointing to the exact location in calcard. This does sound like a real bug: when only a single occurrence override is written back, the exporter should first copy in the base event’s inherited properties (title, location, participants, alarms, etc.) that aren’t explicitly overridden, rather than only serializing the changed fields into the JSCalendar/iCalendar override. That matches how RFC 8984/8984bis (and iCalendar RECURRENCE-ID overrides) are supposed to work: an override patch is meant to be merged onto the master event when read, not treated as a complete standalone event.
This is a code-level defect report rather than a documentation question, so I can’t resolve it from the docs, but I’ve flagged it clearly here for staff/maintainers to confirm and fix in convert.rs. A community member or staff member will follow up on the report itself.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
This has been fixed in the v1.0.0 branch some days ago but the change can’t be backported to v0.16 at the moment. v1.0.0 is expected for late October/early November.