Open Bug 451696 Opened 16 years ago Updated 2 years ago

CalDAV Provider doesn't handle REQUEST/CANCEL correctly

Categories

(Calendar :: Provider: CalDAV, defect)

defect

Tracking

(Not tracked)

People

(Reporter: dbo, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [caldav-sched])

Attachments

(1 file)

1. Organizer schedules an event, sending out iTIP to attendees.
2. Attendee accepts event.
3. Organizer deletes event, sends out CANCEL notifications to attendees.
=> CANCEL isn't handled, event should be deleted (if already accepted).
Flags: blocking-calendar0.9+
I've already started looking at this, but had not yet figured out what the iMIP behavior is. Can you clarify the "if not already accepted" bit? What should happen if not already accepted? Change STATUS to CANCELLED and leave in calendar?


I have looked at this, too, and think we should use (and fix/align) the itip processor as iMIP does; assigning to me.
Assignee: nobody → daniel.boelzle
The same applies for multiple REQUESTs. We need to sort out outdated REQUESTs (SEQUENCE/DTSTAMP) as well. Scenario:
1. Organizer invites attendee.
2. Organizer modifies event, sends out further REQUEST.
=> Random REQUESTs items are shown in view.
Summary: [CalDAV] Provider doesn't handle CANCEL correctly → [CalDAV] Provider doesn't handle REQUEST/CANCEL correctly
Whiteboard: [needs patch]
CalDAV scheduling doesn't block any longer (bug 452610), though it's still wanted for experimental usage.
Flags: blocking-calendar0.9+ → wanted-calendar0.9+
Whiteboard: [needs patch]
Depends on: 457203
Flags: wanted-calendar0.9+ → blocking-calendar1.0+
Summary: [CalDAV] Provider doesn't handle REQUEST/CANCEL correctly → CalDAV Provider doesn't handle REQUEST/CANCEL correctly
Does this really block 1.0?
Flags: wanted-calendar1.0+
Flags: blocking-calendar1.0?
Flags: blocking-calendar1.0+
While unfortunate, I don't think this blocks 1.0. We will take patches if someone is interested though.

Ingo, this might be interesting for you in the Summer. Temporarily assigning to you, if anyone else wants to work on it please comment on this bug!
Assignee: dbo.moz → ingomu
Flags: blocking-calendar1.0? → blocking-calendar1.0-
Whiteboard: [caldav-sched]
Assignee: ingomu → nobody
Attached image cancel_event.png

I just encountered this issue in TB 85.0b3 (64-bit)...

Basically after receiving an invite and accepting it, it was added to my network CalDAV calendar.

But when I received a Cancellation notice (see attached) from sender, I was not able to Accept the Cancellation nor the event disappeared from my calendar automatically (or was marked cancelled with reminder set removed), despite showing "This message contains an event that has already been processed." notification in the email message.

@Thomas, maybe something to fix for enterprise environment?

Flags: needinfo?(bugzilla2007)

(In reply to Richard Leger from comment #7)

But when I received a Cancellation notice (see attached) from sender, I was not able to Accept the Cancellation nor the event disappeared from my calendar automatically (or was marked cancelled with reminder set removed), despite showing "This message contains an event that has already been processed." notification in the email message.

Indeed, that looks wrong! I would probably expect to see at least one button for this case:
Mark cancelled in my calendar (maybe another one: Delete event).
We cannot just delete the event, because even if it was cancelled, it might have some personal information which I still need.
What is the expected behaviour wrt sending out a message back to the sender who cancelled?

@Thomas, maybe something to fix for enterprise environment?

I'd think yes, but I'm not a calendar expert. Strange though that we have not received even a single comment or duplicate report since this bug was filed more than a decade ago. Any explanation for that? I personally cannot fix it, but let's add it to the tracker.

Flags: needinfo?(bugzilla2007)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.