[dev] Changing start time of a recurring event series.

[Michael J Rubinsky]

In working on EAS 16 support, I've come across an issue that needs addressing.

The main purpose of EAS 16 is to improve reliability in calendar  
synchronization - especially with respect to recurrence.  One of the  
changes in the protocol (paraphrased from the specs):

"In protocol version 16.0, changing the start or end time of a  
recurring series will delete any exceptions
present on the calendar item."

Indeed, when using a 16.0 capable client, editing the series on the  
client does remove all the exceptions on the event. While this *does*  
make sense to me, since the exceptions were made based on a different  
original event - it's not how kronolith currently works.

Exceptions are keyed to the base event by the "exceptionOriginalDate"  
- which is basically the timestamp of when the event would have  
normally occured before it was added as an exception (this is true in  
both Kronolith and ActiveSync clients).

I think we should change Kronolith to behave the same as EAS 16 - that  
is changing the recurrence series start/end times should remove all  
exceptions. This is why:

1) While we currently make an attempt to update the  
exceptionOriginalDate when events are modified in Kronolith, this only  
works if the start/end times haven't moved to a different day and the  
recurring series type hasn't changed. E.g., see Bug: 13512. This  
"fixed" the issue, but only because the events don't change days and  
the series hasn't otherwise drastically changed (like going from every  
week to every other week). This is because we can't make a 100%  
accurate assumption as to what day any particular exception would have  
normally fallen on - or even if it would have normally occurred on  
that day anymore.

2) It's inconsistent with how a major sync protocol now works. Yeah, I  
know this is a weak argument, but consider the main reason for  
updating the protocol was to fix many of the things that were causing  
issues with recurring events.

3) There is no way to prevent the exceptions from being removed on the  
client - it does so automatically (and does NOT issue any delete  
commands to the server because it's assumed that they will be removed  
server side). So this MUST be implemented this way when the change  
comes from an ActiveSync client. Otherwise, the sync client and the UI  
will no longer be in sync. Implementing it in one spot doesn't make  
much sense to me - and initial trials in this regard led to duplicated  
events on both the client and UI.

Since this is a fairly big change from a user experience view, I  
wanted to get some feedback here before implementing this. The other  
option is to disassociate the exceptions from the base event - turning  
them into "normal" events any time the base event's start/end times  
change or the series properties change. This is more complicated  
because we need to add those events as new so the history system picks  
them up to sync. It also still leads to inconsistencies between the  
behavior when editing on the client vs the UI.

-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20160121/8e3e3468/attachment.bin>