536796 - copying a recurring (repeating) event creates a new event where some fields cannot be modified

Status: NEW

(Calendar :: General, defect)

Description

[juergen.edner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0

If you copy/paste a full day recurring event not all of the newly created event are changeable anymore.


Reproducible: Always

Steps to Reproduce:
1. create a full day recurring event in an ical calendar.
   (see attachement lightning_recurring_event-error-1.jpg)
2. copy/paste this event to a new day
3. try to change the calendar or recurring interval of the newly created event.
Actual Results:  
It's not possible to change the calendar or the recurring interval of the newly created event. (see attachment lightning_recurring_event-error-2.jpg)

Expected Results:  
It should be possible to change the calendar or the recurring interval of the newly created event.

---step 1: created recurring event ---
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
X-WR-CALNAME:test
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VEVENT
CREATED:20091226T152956Z
LAST-MODIFIED:20091226T153253Z
DTSTAMP:20091226T153253Z
UID:ab71a04d-626a-4de2-b015-5fe645b8fa66
SUMMARY:Test-Event
RRULE:FREQ=DAILY;COUNT=3
CATEGORIES:Privat
DTSTART;VALUE=DATE:20100104
DTEND;VALUE=DATE:20100105
LOCATION:Home
TRANSP:TRANSPARENT
X-MOZ-GENERATION:2
END:VEVENT
END:VCALENDAR
---step 2/3: the newly created event---
BEGIN:VEVENT
CREATED:20091226T153358Z
LAST-MODIFIED:20091226T153358Z
DTSTAMP:20091226T153358Z
UID:d010623f-b199-4105-ba3e-5f9c3bb17a88
RDATE;VALUE=DATE:20100108
DTSTART;VALUE=DATE:20100108
DTEND;VALUE=DATE:20100113
X-MOZ-FAKED-MASTER:1
END:VEVENT
BEGIN:VEVENT
CREATED:20091226T153253Z
LAST-MODIFIED:20091226T153358Z
DTSTAMP:20091226T153358Z
UID:d010623f-b199-4105-ba3e-5f9c3bb17a88
SUMMARY:Test-Event
RECURRENCE-ID;VALUE=DATE:20100108
CATEGORIES:Privat
DTSTART;VALUE=DATE:20100108
DTEND;VALUE=DATE:20100109
LOCATION:Home
TRANSP:TRANSPARENT
X-MOZ-GENERATION:2
END:VEVENT
---a new non-recurring reference event---
---should look like this-----------------
BEGIN:VEVENT
CREATED:20091226T153859Z
LAST-MODIFIED:20091226T153921Z
DTSTAMP:20091226T153921Z
UID:8f24e03e-549a-4c6b-8dc3-807d18dc1980
SUMMARY:Test-Event-2
DTSTART;VALUE=DATE:20100109
DTEND;VALUE=DATE:20100110
LOCATION:Home
TRANSP:TRANSPARENT
END:VEVENT
-----------------------------------------

Comment 1

[juergen.edner]

Attachment: The recurring event which is being copied

Comment 2

[juergen.edner]

Attachment: The newly created event with blocked field entries

Comment 3

[Stefan Sitter [:ssitter]]

I can reproduce the issue.

The Copy command just copies the selected item but not the master item series.

The Paste command creates a faked master item series that contains only the new item occurrence that was copied. The new occurrence behaves like an edited occurrence of a repeating event and therefore prevents you from changing parameters that are based on the master item series.

Not sure what the correct behavior could be. Different possibilities:
1.) Copy+Paste creates an identical copy of the entire repeating event, not just the single occurence
2.) Paste adds an additional occurrence to the existing repeating event using RDATE property
3.) Paste creates a new non-recurring event from the occurrence without the faked master item overhead.
4.) Copy+Paste behavior keeps the same but edit behavior will be changed for occurrences with the faked master item.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I think #2 or #3 makes most sense.

Comment 6

[Thomas Payen]

Any news on this bug ?
I don't really understand why Lightning create a FAKED-MASTER on the paste command ?
It's add a lot of problems ... DELETE is not a DELETE, ACK the alarm does not change the DTSTAMP of the event, etc.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The idea behind the faked master was that for some items (especially itip), you only have the single occurrence available, but not its master item. The faked master is created so the occurrence has a parent item.

I don't think this is sensible on copy/paste and I'm not entirly sure why some details can not be modified. I think to fix this bug correctly, we should go for option #2 if pasting into a calendar that has a master item for the occurrence and option #3 when pasting into a calendar that doesn't.

I have no news when this will be fixed though, noone is working on it.

Comment 8

[Jon]

Copy and paste should replicate the original event which can then be edited with new parameters. Otherwise paste would have to have several options (ie 1-4 as above). Starting with a complete copy of the master would help.

Comment 9

[Profpatsch]

Same bug on Linux Ubuntu x64. Please add this to the platform.

I would prefer the solution for pasted entry to be an identical copy of the master.
I wanted to duplicate birthday entries—which are yearly of course—so I’d only have to change the name field. For this to work I need a copied master and that’s the behaviour I’d expect anyway.

Comment 10

[Alexandre Demers]

So, since I'm working on bug 705596 and I'm hitting this bug when trying to fix it, I'd like to know what should be done. Philipp is suggesting options 2 and 3, while Jon is suggesting option 1.

Profpatsch's case points to option 1. I would be tempted to go with options 2 and 3 as Philipp suggested, even though options 1 and 3 would probably be quicker to fix from my perspective (according to bug 705596 I mean). I don't have any problem working on both bugs since I'm stuck in the middle and one cannot be completed without the other. Point me the direction and I'll work on it.

Comment 11

[Matthew Mecca [:mmecca]]

I think copying the entire series as in option 1 is better implemented with its own UI as in Bug 393084. Option 3 makes the most sense to me, keeping the behaviour consistent regardless of the target calendar.

Comment 12

[Michael]

As there are certainly multiple needs depending on the situation, I would prefer being prompted through a pop-up to decide between action #1, 2 or 3.

Comment 13

[Alexandre Demers]

Then should we go with the same solution for copying any recurrent events, either its the original recurrence set or one of its exceptions? I would say that if you are copying an exception of a recurrence set, it should be either option 2 or 3. Here, a dialog could ask to select one of the two options.

I'm not in favor of option 1, because it can be done through option 3 by copying as a first step the event and by modifying it as a second step as a recurrent event.

Comment 14

[Alexandre Demers]

But I do see in the light of bug 393084 that option 1 should be considered. Well, is this is what people want, let me know. That would kill three birds with one strike.

Comment 15

[Alexandre Demers]

Here is what I see:
Copying a recurrent event could propose a dialog with options 1, 2, 3.
Copying an exception could propose a dialog with options 2, 3.

However, in the case we are copying a recurrent event, should the exceptions be copied or not?

Comment 16

[Michael]

Hmmm, I would think the exceptions should be copied. Either way, it might be good to show a notification in case there are any exceptions, telling whether or not they are being copied.

Copying a recurring event is a complex function that is not done often enough by most people for them to know exactly what will happen when. So I think this warrants a bit more verboseness than would be customary with other, more frequently used functions.

Comment 17

[Matthew Mecca [:mmecca]]

(In reply to Alexandre Demers from comment #15)
> Here is what I see:
> Copying a recurrent event could propose a dialog with options 1, 2, 3.
> Copying an exception could propose a dialog with options 2, 3.

The problem with using a single prompt is that the decision to copy a single occurrence or the entire series (option 1) needs to happen when copying, while the decision between pasting as a new occurrence or as a new item (options 2 and 3) needs to happen when pasting, depending on whether the target calendar is the same as the source calendar. I think if we're going to continue to support pasting as a new occurrence (option 2) we should do as Philipp said in comment #7 rather than confuse the user with multiple dialogs.

The prompt for copying a single occurrence or entire series could use the same prompt we use for modifying/deleting.

> However, in the case we are copying a recurrent event, should the exceptions
> be copied or not?

A common use case for copying an entire series might be to paste into another calendar, so I think that exceptions should be included. This is already possible if you choose "All Events" as the filter in the unifinder and copy a repeating item from there, and I think that behaviour is correct.

Also, I think in this case the copied exceptions need to be shifted at paste-time based on the selected date, since we do this for non-repeating items. Sorry, I know that doesn't help you much with the problem you're trying to solve in Bug 705596.


(In reply to Michael from comment #16)
> Hmmm, I would think the exceptions should be copied. Either way, it might be
> good to show a notification in case there are any exceptions, telling
> whether or not they are being copied.
> 
> Copying a recurring event is a complex function that is not done often
> enough by most people for them to know exactly what will happen when. So I
> think this warrants a bit more verboseness than would be customary with
> other, more frequently used functions.

I think we need to be careful here, too much verbosity / too many options could confuse the user more rather than clarifying.

Comment 18

[Matthew Mecca [:mmecca]]

> A common use case for copying an entire series might be to paste into
> another calendar, so I think that exceptions should be included. This is
> already possible if you choose "All Events" as the filter in the unifinder
> and copy a repeating item from there, and I think that behaviour is correct.
> 
> Also, I think in this case the copied exceptions need to be shifted at
> paste-time based on the selected date, since we do this for non-repeating
> items. Sorry, I know that doesn't help you much with the problem you're
> trying to solve in Bug 705596.

On further thought, it's not that easy to move multiple events to another calendar via copy/paste since you have to select the earliest start date of the copied events to get the rest to end up at their original dates. Maybe another solution would be to shift dates only in the case of a single pasted item or occurrence, and leave the dates as-is in the case of a series and/or multiple selected items/occurrences.

Comment 20

[Christophe Humbert]

Hello,

I think we really need to move on managing recurring event and their exceptions Bug 705596, this one, bug Bug 393084 and maybe others...

My coding abilities are a bit rusty so I think I will make things worse ....but I am sure there are plenty cool dev out there

Comment 21

[Mateusz Bysiek]

Hi everyone,

I've come across this bug on Ubuntu 14.04 x64 and Windows 7 x64.

From all the solutions mentioned above the "simplest copy" solution (i.e. whenever an instance of recurring event is copied, create a new detached event, without any faked master or some other strange things) seems to make most sense to me.

To phrase it in a different way, I vote for: "If any item of the series is copied, only that item is pasted as a new single event, completely separate from the recurring event it came from."

The reason why this solution seems to be the best in my opinion, is that it is the simplest approach. Unless you can easily manage all exceptional occurrences of the event (for example: one event that is weekly on Thursday AND first Sunday of month AND last Monday AND on April 1 2015) there is no point in creating such a single recurring event with complicated rules and exceptions.

Right now I cannot seem to find a way to create a complex event such as example above, so I create several to achieve that. And if the only way of managing those would be copy+paste... I will not think it is a good solution.

I would really like to see this solved. But, there seems to be no consensus over what the solution should be. What can I do to change it?

Comment 22

[Ulrich Windl]

I partially disagree with comment #21: First a copy should be a completely separated instance with preferably every data item being identical to the original. In case the original has an unique ID, that ID has to be changed of course, and any references should be adjusted to let the copy look as an item independent of the original.
What seems to be a typical use case for copying recurring events? I think of some event that occurs on Mondays for some limited time. Then you'll have a very similar event in the same time interval, but on Wednesdays. It is very tempting to copy the Monday event, and then adjust Monday to Wednesday in the copy.

Comment 26

[JGH]

I would agree with comment 21, and option 3 in comment 3: if copying+pasting just create a new, 'stand-alone' non-recurring event (which can be then be changed to repeat as desired). Possibly a message should be produced saying 'Unable to copy/paste repeating event, setting to non-repeating' (or words to that effect). 

This seems far and away the simplest solution, trying to do anything else it will be difficult enough to decide what should be done in all cases will be hard enough, let alone doing it. I think in many cases it will actually provide what is wanted, and if not at least it is a definite situation which can be changed as required. The problem with the current position - at least in part - is that it's unclear what has happened, and creates a record that at least partially cannot be edited.

Comment 27

[Ulrich Windl]

Actually I don't understand: If you have some event (say repeating on a daily base), and you want to copy that event in order to change the starting time or day (just to save yourself some typing work), why is that so complicated (read comment #7)? It works on Android!

Comment 28

[u679463]

Hallo,
In TB 68 and TB 78 the location is not copied and cannot be edited.
The ics files can also not be used in other calendars, because sections with X-MOZ-KAKED-MASTER:1 are considered as correct appointment and therefore are displayed incorrectly.

Any news?