Currently, DAVx5 increases the SEQUENCE of dirty instances of recurring events, but synctools increases the SEQUENCE of the main event during the mapping to VEvents.
Instead, we should have that functionality in synctools.
Idea
AndroidRecurringCalendar provides the above-mentioned method (instead of DAVx⁵). It iterates through dirty events and exceptions and creates an extended row with a flag that defines how SEQUENCE should be handled for each event:
- Main event is dirty → main event gets "increase sequence" flag
- Only instance is dirty → instance gets "increase sequence" flag, main event gets "don't increase sequence" flag
- Events that already have a flag are not processed (to avoid increasing the sequence multiple times, for instance on a failed upload).
The AndroidEventProcessor can then generate increased SEQUENCE fields according to the flag.
The flag is cleared on clearDirty(), which then finally increases the locally stored SEQUENCE.
Further improvements
The SEQUENCE should only be increased on important updates, not on attendee status changes.
There's a feature in the Calendar provider that can be used to see what the changes were:
Currently, DAVx5 increases the
SEQUENCEof dirty instances of recurring events, but synctools increases the SEQUENCE of the main event during the mapping to VEvents.Instead, we should have that functionality in synctools.
Idea
AndroidRecurringCalendarprovides the above-mentioned method (instead of DAVx⁵). It iterates through dirty events and exceptions and creates an extended row with a flag that defines howSEQUENCEshould be handled for each event:The
AndroidEventProcessorcan then generate increased SEQUENCE fields according to the flag.The flag is cleared on
clearDirty(), which then finally increases the locally storedSEQUENCE.Further improvements
The
SEQUENCEshould only be increased on important updates, not on attendee status changes.There's a feature in the Calendar provider that can be used to see what the changes were: