451455 - CalDAV provider can delete items mistakenly

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Bruno Browning]

Attachment: check for inbox == calendar

Most CalDAV servers which support scheduling present the scheduling-inbox at a different URL from the calendar proper, The CalDAV provider currently assumes this is the case, and when the user, for instance, accepts an invitation we modify the item, write it to the calendar proper, and delete it from the inbox. SOGo (at least) presents the inbox at the same URL as the calendar, so when we delete the item from the inbox we delete the item, period. Because of the way that this aspect of caldav-sched support is implemented, this effects all item modifications on SOGo, not just actions on invitations.

Posting WIP patch. This prevents the inadvertent/inappropriate deletion and also keeps refresh() from checking both calendar and inbox, since they are the same. Patch seems to work for me and is at Inverse for testing there.

There is a somewhat similar issue with Google Calendar's CalDAV support: GC advertises the scheduling-inbox at a different URL than the calendar proper, but places invitations in the calendar rather than the inbox. It also does unfortunate things when queried about the inbox. So we may want to adapt this patch to also just not do pollInBox() on GC as well as SOGo.

Comment 1

[Daniel Boelzle [:dbo]]

I am still wondering why they store the inbox iTIP messages side-by-side with calendar data in the calendar collection. How does that work? Is that valid caldav sched or am I getting this wrong?

Comment 2

[Bruno Browning]

(In reply to comment #1)
> I am still wondering why they store the inbox iTIP messages side-by-side with
> calendar data in the calendar collection. How does that work? Is that valid
> caldav sched or am I getting this wrong?
> 

It seems odd to me, too, but as far as I can tell draft 4 of the spec does not actually forbid it - possibly because the drafters never imagined the SOGo behavior. Certainly the workflows described there assume that inbox and calendar are distinct collections. I think the Google behavior is simply wrong by draft 4.

Comment 3

[Daniel Boelzle [:dbo]]

(In reply to comment #2)
> calendar are distinct collections. I think the Google behavior is simply wrong
> by draft 4.
We may consider dropping caldav sched support for Google in case the provider code would be hurt too much.

Comment 4

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

Attachment: check for inbox == calendar - v2

This slightly adapted version of the patch saves a flag on the calendar, which makes the needed workarounds for Google become very minimal (i.e only in the existing specialcasing block).

Comment 5

[Daniel Boelzle [:dbo]]

Comment on attachment 334841 [details] [diff] [review]
check for inbox == calendar - v2

looks good, though I haven't tested it; r=dbo

Comment 6

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

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED