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

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> 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.

I think that's a viable solution. And the UID will change anyway,  
since disconnecting the exceptions from the base event will make them  
a new, independent event.

> 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.

I guess we have to live with this and can always blame it on the  
client if someone complains ;-)

-- 
Jan Schneider
The Horde Project
http://www.horde.org/