On So, 2011-11-06 at 18:27 +0100, Ove Kåven wrote:
> Den 05. nov. 2011 21:21, skrev Patrick Ohly:
> > On Sat, 2011-11-05 at 14:24 +0100, Ove Kåven wrote:
> >> Den 05. nov. 2011 13:27, skrev Ove Kåven:
> >>>> You can comment out the whole <parameter></parameter> part or remove it
> >>>> to try out whether it works.
> >>>
> >>> I'll give it a shot, thanks...
> >>
> >> Well, that works for the entries where SyncEvolution is adding EXDATEs
> >> itself, but for those EXDATEs which have already been pushed to Google
> >> and is coming back from Google with TZIDs, there's still a problem... I
> >> suppose it'll take a rule for the non-auto-generated EXDATEs too.
> >
> > Attached two patches, both also committed to the maemo5-recurrences
> > branch.
> >
> > The first one should suppress the TZID also for regular EXDATEs.
> >
> > The second one attempts to add that time zone information back when
> > reading from the storage.
> >
> > Both patches are completely untested.
>
> diff --git a/src/syncevo/configs/scripting/11calendar.xml
> b/src/syncevo/configs/scripting/11calendar.xml
> index fe38eb6..c47958f 100644
> --- a/src/syncevo/configs/scripting/11calendar.xml
> +++ b/src/syncevo/configs/scripting/11calendar.xml
> @@ -193,8 +193,10 @@
> // the Maemo calendar storages because it uses EXDATE
> // without TZID.
> if (!ISFLOATING(DTSTART)) {
> - STRING tz = TIMEZONE(DTSTART);
> + STRING tz;
> + tz = TIMEZONE(DTSTART);
> if (tz != "UTC") {
> + INTEGER i;
> i = 0;
> while (i<SIZE(EXDATES)) {
> if (ISFLOATING(EXDATES[i])) {
>
> Anyway, it seems to work, now there are no more visible duplicates in
> the calendar.
Thanks, merged with that fix into master.
Once it hit master and was included in testing (which it will be in the
future without having to merge first, thanks to the new automatic
integration testing), I found some drawback in that approach. Fix is in
master, you might want to back-port (without the tests):
commit ede6e65ccb7cf4180711a56c6a28c4914b25a7dd
Author: Patrick Ohly <[email protected]>
Date: Mon Nov 14 12:00:37 2011 +0000
CalDAV: filter out X-SYNCEVOLUTION-EXDATE-DETACHED
If the engine got a parent event with X-SYNCEVOLUTION-EXDATE-DETACHED,
merged it internally and then wrote it back, the
X-SYNCEVOLUTION-EXDATE-DETACHED would have been stored in the CalDAV
server. Now this is avoided by removing all such properties before
storing the new or updated event.
This was previously done (and still is) as an extra precaution in the
code which adds the properties.
commit 1cd49e9ecd60b38593ef87665fe318aec7692d91
Author: Patrick Ohly <[email protected]>
Date: Sat Nov 12 12:50:09 2011 +0000
CalDAV: revised RECURRENCE-ID -> EXDATE support
The previous approach (updating the internal cache) had the drawback
that X-SYNCEVOLUTION-EXDATE-DETACHED was also sent to the CalDAV
server. The work of generating it was done in all cases, even if not
needed. Found when running the full test suite.
Now the X-SYNCEVOLUTION-EXDATE-DETACHED properties are only added to
the icalcomponent that is generated for the engine in
readSubItem(). There's still the risk that such an extended VEVENT
will be stored again (read/modify/write conflict resolution), so
further changes will be needed to filter them out.
To ensure that this change doesn't break the intended semantic of
X-SYNCEVOLUTION-EXDATE-DETACHED, the presence of these properties is
now checked in the LinkedItems::testLinkedItemsParentChild test.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
