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

[Michael J Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>
>> 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.
>
> Not going into depth whether EAS 16's behavior makes more sense than  
> Kronolith's, but my first reaction is: it may be fine to delete  
> empty exceptions from recurring events. This may still be a bit  
> annoying or maybe confusing to some users, but at worst, they have  
> to delete the occurence again. But deleting an exception *event* is  
> unacceptable IMO. This would be data loss to the user, because the  
> edited exception event may contain important information not  
> available in the base recurring event.

I definitely see your point about losing information.

What about my suggestion about totally disconnecting the exceptions  
from the series when the series changes via the UI? If the series  
start or end time changes such that the date changes OR the recurrence  
rule itself changes, then existing exceptions will currently become  
corrupt. They are still bound to the base event, but the  
exceptionOriginalDate value will be wrong. In fact, if the rule itself  
changes, an existing exception may even be for an instance that no  
longer would have occurred at all (granted, this is probably a fringe  
case). This doesn't have a huge impact if only using the kronolith UI,  
but any export of the calendar - including EAS, ics files etc... -   
will be corrupt. The downside to this is that there will be some event  
duplication in both the UI and sync clients for these exceptions  
(which is one of the issues this change in EAS was meant to resolve)  
and visually the disconnected exceptions will no longer show the  
little exception bubble-icon. Perhaps we can append a note in the  
event's description that it was originally an exception to an event. I  
still have to work out how to work around this when sending the change  
to the EAS client. Will probably have to delete the event and recreate  
it completely to avoid issues though this will change the UID.

Either way, when using an EAS client, the exceptions WILL be removed.  
Unfortunately there's nothing we can do about this. I was incorrect  
before when I said the client doesn't issue a delete for them - it  
doesn't always do so explicitly, but rather the recurrence series is  
replaced in it's entirety.


-- 
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/20160122/4b1f056d/attachment.bin>