Re: Changing start time of a recurring event series.

Zitat von Michael J Rubinsky <[email protected]>:

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

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

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]