377141 - [Proto] Invitations dialog: Accept or Decline an invitation -> state isn't saved

Status: VERIFIED FIXED

(Calendar :: Provider: WCAP, defect)

Description

[Andreas Treumann]

STEPS TO REPRODUCE:
===================

- open the invitations dialog
- accept or decline one of your invitations
- restart TB

RESULT:
=======

- the counter shows the old number of invitations 

EXPECTED RESULT:
================

- the counter shows n-1 invitations

REPRODUCIBLE:
=============

- always

Comment 1

[Daniel Boelzle [:dbo]]

In general, accepting/declining WCAP invitations currently doesn't work, because the attendee cloning (e.g. X-attribs) still hasn't been fixed. There is bug 358498 which has two patches I had submitted which both fix that problem. I would suggest to take patch 250846 "fixing rsvp and cloning" leaving the API "as is" (i.e. rsvp is still modelled as bool). That patch actually had been reviewed, but hadn't been in because of ongoing API discussion (undefining RSVP etc).

Comment 2

[Daniel Boelzle [:dbo]]

Attachment: clone old item

- clone old item, because WCAP provider works on diff to old item
- js nit

Comment 3

[Michael Büttner (no reviews TFN)]

Comment on attachment 261452 [details] [diff] [review]
clone old item

>-            var newCalendarItem = (oldCalendarItem.isMutable)
>-                ? oldCalendarItem : oldCalendarItem.clone();
>+            var newCalendarItem = oldCalendarItem.clone();
This is exactly the same problem I had with the event dialog. Conditionally cloning the item opens up the problem for providers relying on the difference between old and new item. I fixed it the same way, just always clone() to ensure the right difference. r=mickey.

I'd like to take this one for 0.5 since otherwise the WCAP invitation feature it pretty unusable.

Comment 4

[Michael Büttner (no reviews TFN)]

patch checked in on trunk an MOZILLA_1_8_BRANCH

-> FIXED

Comment 5

[Andreas Treumann]

I checked this in the latest nightly builds -> task is fixed and verified.