Spinoff from bug 328576: > * All providers also need to handle this case in addItem for import, iMIP, > copy/paste.
import has been fixed in bug 364841. Is there extra work to be done in iMIP and copy/paste?
Not going to make the 0.5 train.
Clint, this is considered release-note-worthy. However, the question from Sebo in comment 1 hasn't been answered for over a year. Could you perhaps shed some light on what still needs to be done here?
IMO this bug relates to the discussion in bug 450653: We need to figure out how copy/paste/drag/drop import works w.r.t. iTIP messages.
Not quite sure what kind of exceptions are meant here. What is the issue here? What is left to do?
I think it has to do with handling exceptions that are thrown because when you do import for iMIP messages you end up trying to insert events that already have the same UID. For instance (I might have this wrong, it's been a long time since I looked at rfc 2446) when you get a "update" iMIP message, the event encapsulated on that message will have the same UID. If you were to drag that message onto the calendar to add it to your calendar then you'd get an error or it would create two events. That's what I think this was about.
I'm using 2 (Google) calendars in the Mozilla Lightning 1b2 addon in Thunderbird and I want to copy a recurring meeting from one calendar to another. When I'm doing that, it looks like the meeting is copied and pasted but there is only one new meeting with the value null.