199422 - some details are lost when you Copy/Paste an event

Status: RESOLVED WORKSFORME

(Calendar :: General, defect)

Description

[Calum Mackay]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326

When copy/paste are used to copy an event, several details from the original
event are not copied over. In particular:

   Start
   End
   this event lasts all day
   calendar file


Reproducible: Always

Steps to Reproduce:
1. Create a new calendar
2. Create a new event in this calendar, ensuring the Start/End times are changed
to something other than the default; e.g. make them several hours on from the
current time.
3. Ensure that calendar file is set to the new calendar created in 1), and click OK.
4. Select the event, and ctrl+c to copy it
5. Select a new (different) day, and ctrl+v to paste the event.
6. The event dialog pops up (why?)
7. Note that the Start/End times & the calendar file have been reset to
defaults. If you require a carbon copy of the first event these now need to be
manually reset.

To see the problem for "this event lasts all day", the reproduction is slightly
more involved:

1. Create a new calendar
2. Create a new event in this calendar, setting "lasts all day".
3. Ensure that calendar file is set to the new calendar created in 1), and click OK.
3b. Create another, dummy, event, on a different day, without "lasts all day
set" (i.e. set it to a real Start/End time.
4. Select the original event, created in 2) and ctrl+c to copy it
5. Select a new (different) day, and ctrl+v to paste the event.
6. The event dialog pops up (why?)
7. Note that the "lasts all day" setting is cleared & the calendar file has been
reset to default. If you require a carbon copy of the first event these now need
to be manually reset.





Reproduced in a brand-new profile

Comment 1

[Mitch]

Confirmed that i can see the reported behavior too. Copying a calendar entry
only seems to copy the text and not the duration of the event, which is
counter-intuitive to what one would expect.

Comment 2

[Calum Mackay]

bit of justification: this is oft-required functionality in some cases, e.g.
when entering shift work duty. If someone works various shifts, which are always
at the same times, but different shifts on different days, they're going to want
to enter the data once, and then copy it to multiple days, with only the date
changing, not the times, or calendar files.

Ease-of-use more than anything else.

Comment 3

[Mike Potter]

New contact from [e-mail] to [e-mail]
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.

Comment 4

[David Fraser]

bug 200703 is a duplicate of this

Comment 5

[Calum Mackay]

*** Bug 200703 has been marked as a duplicate of this bug. ***

Comment 6

[[e-mail]]

Noticed here too, copying events loses the start/end time...Calum I can
understand the justification for losing the start/end time, but if its true then
I can think of two options to make this clearer to everyone else.
1)have something in options to allow you to disable this to allow "true"
copy/paste functionality.
2) when copy/pasting an event that loses the times, perhaps it should
automatically open the event for editing to allow the times to be entered right
away as a reminder.

Comment 7

[Len Weisberg]

[e-mail]  wrote in comment #6
> I can understand the justification for losing the start/end time

Please explain. Certainly the date part will change, but how can you
justify changing the time?

I reported Bug 200703, which is a duplicate of this bug and my main
motivation was that the start/end times were not preserved.  If this
bug can be resolved in such a way that start/end times change, then
Bug 200703 is not a duplicate.

Comment 8

[Len Weisberg]

I just noticed that this bug is marked  OS: Linux, but the duplicate,
Bug 200703, is marked  OS: All .
I believe this bug should also be  OS: All .

Comment 9

[John Schuetz]

*** Bug 254529 has been marked as a duplicate of this bug. ***

Comment 10

[John Schuetz]

If one uses multiple calendar files this bug is very annoying because one cannot
change the calendar file association through the "Edit Event" dialog.  This
essentially renders cut/copy and pasting useless for all but the default
calendar file, and, in my mind at least, greatly hampers the usefulness of
Calendar, which is otherwise very nice.

Comment 11

[Vincent Lefevre]

And if one isn't aware of this bug, one may think that data (pasted events) were
lost: in my case, the events of the default calendar aren't visible as this
calendar isn't selected (though pasted events are stored to it).

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 258022 has been marked as a duplicate of this bug. ***

Comment 13

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 258547 has been marked as a duplicate of this bug. ***

Comment 14

[mike]

I suggest adding the word 'paste' to the summary.  I found this bug difficult to
find, was searching copy AND paste; prehaps this is causing so many duplicates.

Comment 15

[Michiel van Leeuwen (email: mvl+moz@)]

*** Bug 259226 has been marked as a duplicate of this bug. ***

Comment 16

[gekacheka]

*** Bug 282290 has been marked as a duplicate of this bug. ***

Comment 17

[gekacheka]

Attachment: pasteFromClipboard: paste modulo grid cell duration, relative to first pasted event

(patch -l -p 2 -i file.patch)

(Note: destination of paste or import is always currently selected calendar
file, which has outline in calendar list, or first file if none selected.)

Old code for paste was primarily for pasting text, so it supplied the
current selected date inappropriately for pasting iCalendar events and todos.

This patch adds code for pasting iCalendar events and todos.
The new behavior is as follows:

When pasting vcalendar events and/or todos,
  If focus is in one of the lists (event list, todo list, calendar list).  
    use the pasted date
  Otherwise, use current grid selected datetime as a basis for pasted events.
    Keep the time offset modulo the grid cell duration
      (Example: Pasting a 14:45 event into a different day cell in month
	 view keeps the 14:45 time of day but sets the day to that day.
       Example: Pasting a 14:45 event into a different hour cell in
	 week view keeps the :45 minutes but updates the hour.)
    Keep each event's offset from the first pasted event.
      (Example: pasting a monday event and a wednesday event together onto
	 tuesday in month view produces a tuesday event and thursday event.
       Example: pasting a 10:00 event and a 12:00 event together into
	 14:00 in week view produces a 14:00 event and a 16:00 event.)
    When pasting events, update both the start and end datetimes.
    When pasting todos,
      If a start datetime is set, update the start datetime,
	and if the due datetime is set, 
	  only if it is between the old and new start datetimes
	    update the due datetime. 
	  (Enables rescheduling, delegating, or dividing future tasks
	     without changing due date.
	   Enables making a later copy of a task with a
	     corresponding new due date.)
When pasting non-vcalendar text
  If focus is in the todo list,
    then create a todo,
    otherwise create an event.
  Paste text into description of new event or todo.
       
The patch also adds calendarWindow.getGridCellDurationMSec(), used above,
which returns the duration initialized by each of the views
(1 day for month and multiweek view, 1 hour for day and week view).


Tested on 0.2 branch (extension on moz1.7.5); can test on trunk after trunk
nightly build becomes available for w2k.

Comment 18

[gekacheka]

Attachment: workaround double utc offset conversion on export/copy

(patch -l -p 2 -i file.patch)

Problem was that copying an event produced a iCalendar text where the timezone
offsets was adjusted twice as far as needed, e.g, for utc offset of 5hrs, zulu
times were local times adjusted by 10hrs.  Seems like for start/end dates
oeDateTime.utc is false, but oeCalendarEvent.getIcalString is still producing
zulu times.

This patch works around problem by commenting out convertLocalToZulu in
eventArrayToICalString.

Tested using sunbird0.2branch calendar extension on Moz1.8b1.
(This workaround might not be required on trunk, because trunk uses new
calendarEvent and dateTime implementations.)

Comment 19

[gekacheka]

Attachment: [OT: patch sb02 cvs files for calendar-extension to remove need for preprocesor.]

(patch -l -p 2 -i file.patch)

[This patch removes the preprocessor '#' comments and '#ifdef MAC_OS' for
non-MacOS programmers who want to try calendar-ext bug patches without doing a
full make.  One alternative way to create the calendar.jar for MozCalendar
Extension without all the tools/compilers for a 'make' is by downloading the
sunbird0.2branch from cvs and applying this patch and the bug patches using
'patch', and making the calendar.jar with 'cp' and 'zip', as described in
http://wiki.mozilla.org/wiki/User:Gekacheka:JarScripts (apply patches in step
4, stop in step 7)]

Comment 20

[D. Schouten]

*** Bug 293874 has been marked as a duplicate of this bug. ***

Comment 21

[gekacheka]

*** Bug 303671 has been marked as a duplicate of this bug. ***

Comment 22

[Joey Minta]

*** Bug 315843 has been marked as a duplicate of this bug. ***

Comment 23

[Joey Minta]

gekacheka (or anyone else), What's left to do here?  I thought I fixed most of these issue in bug 300250.

Comment 24

[gekacheka]

The patch for this bug worked as described with examples in comment 17.

Currently Sunbird (as patched by bug 300250) enables pasting multiple events to a different start day, but does not enable pasting them to a different start hour (in day and week view) as the patch for this bug did.

Further work might wait for the new views land (bug 297934).

Comment 25

[Joey Minta]

Given our current selection behavior in the views, dmose and I agree that this isn't dataloss anymore.

Comment 26

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 27

[Eve McGivern]

Slightly different, but this issue also occurs when pasting on same day across different calendars. Tested with month view for all-day events; I could not consistently reproduce with single-day timed events.

Steps to recreate:
1. Create all-day event on any day in Calendar A
2. Copy this all-day event from Calendar A
3. Create Calendar B if not already present.
3. Paste to same day in Calendar B

Expected results:
Duplicate information from Calendar A listed on Calendar B, but showing as posted to Calendar B.

Actual results:
Showing as posted to Calendar B, but event spans one day before as well as that day.

------------

Findings:

Downloaded nightly build 07/25/2006 and tested; issue appears resolved. (Note: adding an event here takes at least two tries, as it does not appear the first time. Appears to be a time delay issue, as I can enter an event successfully the first time if I wait about 1 minute after starting application.)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-0; en-US; rv:1.9a1) Gecko/20060725 Calendar/0.3a2+.

PC users using Build ID Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060705
Sunbird/0.3a2+ did not report this problem.

Comment 28

[Bas van den Bosch]

adding qa-wanted. Can mac-users confirm this works now? As commented by Eve, I had no problem with sunbird 0.5pre (2007042703) on windows.

Comment 29

[Galen Stansell]

I am using 0.5rc1.  Slight variant of this bug?  Copy and paste an event that is not an all day event but has a repeating pattern - in my case repeat daily for 5 occurences.  I get first day of event successfully copied, but repeating attributes lost.  Further, and more importantly, when I close sunbird and come back in, the copy/pasted event is gone.

Comment 30

[Stefan Sitter [:ssitter]]

(In reply to comment #29)
No, you are seeing Bug 345607.

Comment 31

[Ruben Merz]

(In reply to comment #28)
> adding qa-wanted. Can mac-users confirm this works now? As commented by Eve, I
> had no problem with sunbird 0.5pre (2007042703) on windows.
> 

I'm on a mac and I can confirm this bug with Lightning 0.5 (build 2007062503) and Thunderbird v2.0.0.6 (20070728).

The 'Calendar' setting is not copied properly when doing CTRL-C, CTRL-V. It is always the default calendar that is selected. It's a bit annoying.

Comment 32

[Philipp Kewisch [:Fallen][☁️📆]]

Ruben, since cut/copy/paste can be used to duplicate/move events between calendars, having the calendar setting change is rather a feature than a bug. If it always pasts into the calendar it came from, no use in cutting it. See bug 366914 also.

Comment 33

[Joelle]

(In reply to comment #31)
> 
> I'm on a mac and I can confirm this bug with Lightning 0.5 (build 2007062503)
> and Thunderbird v2.0.0.6 (20070728).

I'm on linux and can also confirm this bug with Lightning 0.7 (build 2007102303) and Thunderbird v2.0.0.12 (build 20080206)

I disagree with Philipp who saw this as a feature. It was very irritating when pasting an event multiple times. I had to go in and change each one to the correct calendar. It belonged to a certain calendar the first time and each subsequent time as well. 

Comment 34

[Martin Schröder [:mschroeder]]

I think all major issues of this (rather old) bug report are resolved. Any remaining or new issue should be filed as a new bug! Anybody who disagrees?

Comment 35

[Daniel Boelzle [:dbo]]

... should reopen the bug