702570 - Change logic to move events between calendars to avoid resource conflicts on servers that use account-unique UIDs (i.e iCloud)

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[Joerg]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

1. Create iCloud calendars (using patch from Bug 695117)
2. Create an event for one iCloud calendar
3. Change the calendar in the event modification dialog box and press ok.


Actual results:

Error message appears
Error code: MODIFICATION_FAILED
Description: Status-Code: 409, Resource-Conflict.

<?xml version='1.0' encoding='UTF-8'?><error xmlns='DAV:'><no-uid-conflict xmlns='urn:ietf:params:xml:ns:caldav'><href xmlns='DAV:'>/XXXXXXXX/calendars/home/cc546ca8-14bd-49e6-aa4a-b18d276c6d47.ics</href></no-uid-conflict><error-description xmlns='http://twistedmatrix.com/xml_namespace/dav/'>(4845915782) Found component /XXXXXXX/calendars/work/cc546ca8-14bd-49e6-aa4a-b18d276c6d47.ics with same UID in a different collection: /XXXXXXXX/calendars/home/cc546ca8-14bd-49e6-aa4a-b18d276c6d47.ics</error-description></error>


Expected results:

New clanedar should assigned to event

Comment 1

[Felix Möller]

I just tried this on my locally installed Apple Calendar Server and there it works.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I've just tested this and it works fine for me. Please verify.

Comment 5

[grb19]

Well, I still get error messages(see below) - I do still believe, that the main problem is, that the Icloud servers do not like to have two same events in two different calendars. Thunderbird wants to copy the event first and then delete the old one, but the mail-server rejects the duplicated event...
(fyi, I'm using Lightning 1.9.1)

P.S.: workaround: move the event temporarily in an non iCloud calendar

-----------------------------------
Zeitstempel: 23.09.2013 18:14:28
Fehler: Beim Schreiben in den Kalender private_iCloud ist ein Fehler aufgetreten! Fehlercode: MODIFICATION_FAILED. Beschreibung: Status-Code: 2147500037, Die Anfrage kann nicht verarbeitet werden.

Server Replied with 403
Quelldatei: resource://calendar/modules/calUtils.jsm -> file:///C:/Users/XXXXXXX/AppData/Roaming/Thunderbird/Profiles/dfj95cyn.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Zeile: 976
------------------------------------
Zeitstempel: 23.09.2013 18:14:28
Warnung: Fehler beim Lesen von Daten für Kalender: private_iCloud. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: DAV_PUT_ERROR. Beschreibung: Beim Speichern des Eintrags auf dem Server ist ein Fehler aufgetreten.
------------------------------------
Zeitstempel: 23.09.2013 18:14:28
Fehler: CalDAV: Unexpected status adding item to private_iCloud: 403
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20130826T143457Z
LAST-MODIFIED:20130923T161428Z
DTSTAMP:20130923T161428Z
UID:XXXX
SUMMARY:Testate & co
DTSTART;TZID=Europe/Berlin:20130828T150000
DTEND;TZID=Europe/Berlin:20130828T161500
X-MOZ-GENERATION:2
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Could you provide more exact steps maybe? Change calendar from what to what? One iCloud calendar to another? Anything else aside from the initial steps to reproduce?

Comment 7

[grb19]

Any changing within the following calendars does not work:

https://p01-caldav.icloud.com/XXXXXXXXXX/calendars/home/
https://p01-caldav.icloud.com/XXXXXXXXXX/calendars/2b6770ea5fb2c5e59c9e6af89e39cc4195339bb56d00543a81de25986e9b4544/
https://p01-caldav.icloud.com/XXXXXXXXXX/calendars/97AF83D4-4247-4180-89D0-BDFFB8324929/

So the change was between two iCloud calendars, which both belong to the same account.
Enabled or disabled offline support does not change anything.
Changing of the receiving server to p02 also has no effect.

Urls were retrieved by the tool, that can be found here:
http://icloud.niftyside.com/

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Ah ok, I have been able to reproduce this now. I just talked to someone from iCloud: Matching with the observations, the item UID is unique to the whole account instead of just a calendar, due to how implicit scheduling works. There is no sensible way to fix this on iCloud, because invitations don't specify a collection but just a UID.

For us to fix this, we would have to drastically change the current logic, which is add to new calendar first, then remove from old calendar on success:

* If moving from caldav to non-caldav, use the current logic
* If moving from caldav to caldav on the same server, use a MOVE operation
* If moving from caldav to caldav between different servers, use the current logic

We can't just delete first then add, because it might cause dataloss. We can't delete, then add and on failure add back to the first calendar, because that last add might also fail due to soft quotas.

To fix this bug, it needs to be implemented in a way that fits in nicely with the providers, but I really think the effort is not worth it.

Comment 9

[grb19]

I'm not quite sure, whether the third way
(* If moving from caldav to caldav between different servers, use the current logic)
would work. Shouldn't it be different accounts and not different servers?

Comment 10

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I'm just saying, this case also needs to be covered given the architecture of Lightning. Calendars are abstracted in a way that a copy/move can happen between any kind of calendar.

Comment 13

[Wayne Mery (:wsmwk)]

comment 8

Comment 14

[Paul Morris [:pmorris]]

This looks like something we should fix eventually, but given the effort involved, I think the priority would be lower, P3 at most.

Comment 15

[Дилян Палаузов]

The rationale for the restriction is, that moving an event by PUT+DELETE for server-side scheduled events, on PUT the server has to send iTIP invitations, and on DELETE the server has to send iTIP cancellations. This is hard to get right. To test on servers with such behaviour, you can use [e-mail] as principal. For various reasons mentioned elsewhere, the easiest setup is to use TbSync+Dav-4-TbSync. The secret is abc.

See also https://github.com/jobisoft/DAV-4-TbSync/issues/187 and https://github.com/cyrusimap/cyrus-imapd/issues/2345.

Comment 16

[Дилян Палаузов]

I mean that account can be used to test HTTP MOVE, and triggers an error, if PUT+DELETE are used instead.

Comment 17

[Дилян Палаузов]

Since it is not explicitly said here how to proceed, I say it:

Lightning shall use HTTP MOVE instead of HTTP PUT followed by HTTP DELETE.