702570 - Change logic to move events between calendars to avoid resource conflicts on servers that use account-unique UIDs (i.e iCloud) - use HTTP MOVE instead of PUT + DELETE to move events/tasks

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.

Comment 19

[[e-mail]]

Thank you for looking into this. It would be awesome to get this addressed, noting that it was first reported 13 years ago. :-)

Comment 20

[[e-mail]]

Is this in the queue to fix? It's a real limitation to not be able to change calendars when editing an event. Thanks!

Comment 22

[yappiest.lizard.dzmf]

I'd like to note, for the record, that this bug is more than a minor calendar inconvenience. For users wanting to manage task lists via CalDAV in Thunderbird, it essentially renders task management unusable, as a core function of a productive workflow is being able to move/reassign to-do items from one list to another. The same bug that prevents assigning a calendar event from one calendar to another also prevents moving a task from one list to another.

My original bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1972179

Comment 23

[yappiest.lizard.dzmf]

An update from Mailbox.org support:
"We have received feedback from Open-Xchange regarding this issue.

When moving an appointment within the account, Thunderbird first creates a copy of the appointment including the UID (unique identifier), which leads to a conflict because there are now two appointments with the same UID. Therefore, the change (moving the appointment) is rejected by the server and not carried out.

According to Internet standards RFC 4918 and RFC 6638, when moving a calendar object within a calendar collection of the same calendar account, the file action “MOVE” must be executed by the server. Mozilla Thunderbird apparently first sends a “COPY” command to the server, which then creates a copy of the appointment and its UID. This results in a UID conflict, which prevents the appointment from being moved.

In my test with another client (EmClient in this case), I found that moving was possible here and that this action is possible in principle.

At this point, we have no influence on the client-side implementation of the handling of moving appointments and therefore cannot effect any improvement. It is conceivable that Thunderbird will make adjustments to enable the use of this feature in the future."