Closed Bug 345607 Opened 15 years ago Closed 12 years ago

Copy recurring event and paste to another day appears to work but event is not saved (has RECURRENCE-ID but no parent item) [clipboard]

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: brent-lambert, Assigned: dbo)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Mozilla Sunbird/0.3a2

I create an arbitrary one-time event and can copy and paste to another day just fine.  However if I try to copy a repeating event and paste it to another day, the paste operation appears to work but when I browse to the next week (or previous week) then back to where I pasted the event, it is gone.

I've tested with events that repeat daily, weekly, and monthly, all with the same results.  I've tested with repeating forever, and with repeating for 5 occurrences.  I've tried it in both week view and month view, and I've tried using the context menu (right mouse) to copy/paste and using Ctrl-C & Ctrl-V.

I'm new to Sunbird, I have very little data.  I currently have 6 local calendars defined (all displayed), but only 2 real events and 1 real task defined, in two different calendars.  The recurring events are brand-new events I've created in a third calendar.

Also, it doesn't seem to matter whether I edit the event after pasting or not.  Either way, the same problem occurs.  The thing is, though, that if you do edit the pasted event, then any data you've added or changed is lost without warning.

Reproducible: Always

Steps to Reproduce:
1.Create a repeating event
2.In the week or month view (maybe others) copy the event using Ctrl-C or the context menu
3.In the week or month view (maybe others) paste the event to another day using Ctrl-V or the context menu
 -- pasted event should appear, though without all data (see other bugs addressing this).
4.Click the left or right arrow at the top of the week or month view to look at either the next or previous time period.
5.Click the opposite arrow to return to the time period in which you pasted the event.
  -- The pasted event is gone.  No sign of it at all.

Actual Results:  
The pasted event is gone.  No sign of it at all.  Not in any of my calendars (all are displayed).  NO error messages, though.  Just loss of data.


Expected Results:  
Saved the pasted event in the calendar from which it was copied, or at least somewhere.

Standard Windows XP Home sp2 configuration.  I also use Firefox and Thunderbird, though I doubt that makes a difference.  I do not have any other calendar software installed.
Confirming this with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1) Gecko/20061006 Sunbird/0.3

there is an older bug related to this (bug 295017) but I would prefer bug 295017 to be duped against this one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Sunbird 0.3
*** Bug 355371 has been marked as a duplicate of this bug. ***
Copy of comment from bug 355371:
>As far as I tried to study this problem, it seems that there is a
>conflict between RECURRENCE-ID attached to the first recurrence and the new
>RRULE line : I think that when copying an event from recurrence, the
>RECURRENCE-ID line should not be copied
Whiteboard: [litmus testcase wanted]
*** Bug 355868 has been marked as a duplicate of this bug. ***
*** Bug 359524 has been marked as a duplicate of this bug. ***
I can still reproduce this bug with latest build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061128 Calendar/0.4a1. No error in console


I've created an event:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061128T191642Z
LAST-MODIFIED:20061128T191642Z
DTSTAMP:20061128T191642Z
SUMMARY:reevent
CLASS:PUBLIC
RECURRENCE-ID;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTSTART;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTEND;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T010000
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20050126_1/Europe/Warsaw
X-LIC-LOCATION:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

Removing RECURRENCE-ID; and pasting the code into calendar helps and resolves the problem. The event is saved.

The new code looks like:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061128T191739Z
LAST-MODIFIED:20061128T191932Z
DTSTAMP:20061128T191932Z
SUMMARY:reevent
CLASS:PUBLIC
DTSTART;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061208T000000
DTEND;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061208T010000
X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property 
 name: TZID=/mozilla.org/20050126_1/Europe/Warsaw
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20050126_1/Europe/Warsaw
X-LIC-LOCATION:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR


I can see an error above: X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property 
 name: TZID=/mozilla.org/20050126_1/Europe/Warsaw

Hope it will help
oh- but new event doesn't repeat
Ok, one line is missed. RRULE:FREQ=WEEKLY;COUNT=5;INTERVAL=1

So it should looks like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VEVENT
CREATED:20061128T191642Z
LAST-MODIFIED:20061128T191642Z
DTSTAMP:20061128T191642Z
SUMMARY:reevent
CLASS:PUBLIC
RRULE:FREQ=WEEKLY;COUNT=5;INTERVAL=1
TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTSTART;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000
DTEND;TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T010000
END:VEVENT
BEGIN:VTIMEZONE
TZID:/mozilla.org/20050126_1/Europe/Warsaw
X-LIC-LOCATION:Europe/Warsaw
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR
The line "TZID=/mozilla.org/20050126_1/Europe/Warsaw:20061206T000000" below "RRULE:FREQ=WEEKLY;COUNT=5;INTERVAL=1" should be also removed to get rid of X-LIC-ERROR;X-LIC-ERRORTYPE=PROPERTY-PARSE-ERROR:Parse error in property 
 name: TZID=/mozilla.org/20050126_1/Europe/Warsaw

I would write a patch for it but unfortunately I don't know how to do it... As I guess something should be changed in /cvsroot/mozilla/calendar/resources/content/clipboard.js
Duplicate of this bug: 368660
Duplicate of this bug: 382529
This bug persists in Calendar v0.5
Flags: in-litmus?
Whiteboard: [litmus testcase wanted]
(In reply to comment #1)
> Confirming this with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1)
> Gecko/20061006 Sunbird/0.3
> there is an older bug related to this (bug 295017) but I would prefer bug
> 295017 to be duped against this one.


This is also happening on Windows / Sunbird 0.5
Duplicate of this bug: 399175
This bug persists in Calendar/Lightning v0.7.
Component: General → Calendar Views
Flags: wanted-calendar0.8?
OS: Windows XP → All
QA Contact: general → views
Hardware: PC → All
Setting wanted0.8- as the main Calendar developers will not devote any time to
this in the 0.8 timeframe. Patches are, of course, always welcome.
Flags: wanted-calendar0.8? → wanted-calendar0.8-
Late for a couple meetings cuz of this bug. 

 Also, what's the point in giving wanted- if it's a critical bug and you'll take a patch? If it's wanted it's wanted.  Blocking- sure if no one will get to it, but certainly it's wanted+?
Don't know if anyone else has noticed this, but after pasting an event to cause the bug, if I switch to mail and then back to calendar it forgets the date I was at too.

Example: I switch to calendar to find myself looking at Weeks 16-19. I click Today to go to 31/03/08, Weeks 14-17. I copy and paste a recurring event. I go back to mail, then back to calendar. The data is lost, as we know (!), but I'm looking at Weeks 16-19 again too.

I've only just signed up to Bugzilla, and I'm amazed such a serious flaw has been around since mid-2006...
Update for v0.8:
Now copy and paste of repeated task did not futher work anymore. The copy action is not a problem. Data is shown in the Clipboard. But the pase action will not work. No new entries are shown.
With a on day task copy and paste is now problem.

I checked the clipboard and removed lines:
UID:ac8004e5-f0dc-4257-b571-9334d692e84e
RECURRENCE-ID;TZID=/mozilla.org/20071231_1/Europe/Berlin:20080331T070000

1. After that the clipboard could be imported by paste in a new task.
2. But now it's a single task instead of a repeated task.

Situation 2. is ok for me because now I can modify the task to an repeated
one.

This problem should be fixed because it's very often used by me.

In my opinion I have a vote of two fixes: UID and RECUREENCE-ID lines
should not export (bad) should filtered by import (better).
Pierre, your issue is the same as the similar bugs bug 357399 and bug 392465. If the parser doesn't have the master item available, then it doesn't know what to do with the occurrence you are pasting. 

Duplicate, or are there other issues this bug needs to stay open for?
this bug is about copying recurent event not importing calendar or accept invitation, I didn't read the two other bug but I don't think that it's the same issue... might be partly related tought
Duplicate of this bug: 427220
Using Sunbird 0.9 and local ics calendar the behavior is still the same. 

But using a local storage calendar the behavior has slightly changed: 

Copy and paste of repeating event is still not possible. But it doesn't look anymore like it appeared to work. No event is displayed on the target day that disappears after reload. Instead the Error Console shows:

    Error: Assert failed: no parent item passed!
    1: [file:///E:/sunbird/js/calUtils.js:1004] ASSERT
    2: [file:///E:/sunbird/js/calStorageCalendar.js:2165] anonymous
    3: [file:///E:/sunbird/js/calStorageCalendar.js:442] anonymous
    4: [file:///E:/sunbird/js/calStorageCalendar.js:398] anonymous
    5: [null:0] null
     = NS_ERROR_UNEXPECTED
    Source file: file:///E:/sunbird/js/calUtils.js
    Line: 1007
Severity: critical → major
Flags: wanted-calendar0.8- → blocking-calendar1.0?
Version: Sunbird 0.3 → Trunk
I think this bug is quite similar to bug 357399.

BTW: is there an existing bug to properly copy all vs. copy the single event? I think we should add such a feature, so we can provide the correct ics to the clipboard.
Depends on: 357399
(In reply to comment #24)
> BTW: is there an existing bug to properly copy all vs. copy the single event? I
> think we should add such a feature, so we can provide the correct ics to the
> clipboard.

Maybe in bug 393084?
Summary: Copy recurring event and paste to another day appears to work but event is not saved → Copy recurring event and paste to another day appears to work but event is not saved (has RECURRENCE-ID but no parent item)
Assignee: nobody → mschroeder
Status: NEW → ASSIGNED
Summary: Copy recurring event and paste to another day appears to work but event is not saved (has RECURRENCE-ID but no parent item) → Copy recurring event and paste to another day appears to work but event is not saved (has RECURRENCE-ID but no parent item) [clipboard]
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Martin, are you still working on this issue?
Assignee: mschroeder → nobody
Status: ASSIGNED → NEW
I looked into this and there is no obvious solution. There is no way to transfer non-text things via the clipboard. I have filed bug 475963 to fix the core issue here, although I doubt it will make 1.9.1 or even 1.9.2.

I have though of some (unfortunately really ugly) workarounds, but I'm not satisfied with them and they aren't really easy to implement:


* call getItem() for each item-unique occurrence to get the parent item from the calendar and add an RDATE.
  - Ugly asynchonous code all over the place.

* create a wrapper around nsIClipboard that saves the nsITransferable and returns
  it if needed
  - I've had Problems with pasting externally
  - A lot of code for a workaround.


I'm not really sure what do about this bug. I'd like to take it off the blocking list since its too much work for too little effect, but the current results don't really look good (Creates "Untitled" events).
Depends on: 475963
Flags: blocking-calendar1.0+ → blocking-calendar1.0?
Until the functionality works, can we just disable being able to copy the recurring event?
Attached patch Fix - v1 (obsolete) — Splinter Review
That was my second though too, but without parsing the items on each canPaste() check, we have no way of reliably disabling the Paste and/or Copy menuitems.

Daniel, maybe you have an idea?
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #359610 - Flags: review?(daniel.boelzle)
Attached patch patch - v1Splinter Review
If I got this bug right, we proceed to follow value semantics when pasting as we currently do for single items (i.e. set a fresh UID).
Thus I think we just need to fix that UID and start-time changes are properly propagated for recurring items. This patch fixes this for me, though I'd appreciate any further testing, since code changes in this area are always highly sensitive.
Assignee: philipp → daniel.boelzle
Attachment #359732 - Flags: review?(philipp)
Attachment #359610 - Attachment is obsolete: true
Attachment #359610 - Flags: review?(daniel.boelzle)
Keywords: qawanted
Comment on attachment 359732 [details] [diff] [review]
patch - v1

>+  /**
>+   * If the base item's UID changes, this implicitly has to change all overridden items' UID, too.
>+   *
>+   * @param id new UID 
>+   */
>+  void onIdChange(in AUTF8String aNewId);
Hmm, can't we just make the overridden item get the ID directly from its parent item?

r=philipp with comments considered.
Attachment #359732 - Flags: review?(philipp) → review+
...like we do with the |calendar| attribute.

I thought about that, too, but refreained for now, because I am not sure whether all client code uses the |id| attribute instead of getting the UID property. We need to keep care of serializing, too. I'll further look st the code and think about it.
I am leaving UID/id consolidation up to future patches.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/06cf82446ca8>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Keywords: qawanted
Flags: blocking-calendar1.0?
Duplicate of this bug: 535661
Duplicate of this bug: 551079
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.