Copy-Paste of recurring event lasting 1hr creates recurring event lasting 24hrs with 'null' as title

UNCONFIRMED
Unassigned

Status

UNCONFIRMED
8 years ago
4 months ago

People

(Reporter: dutch_gemini, Unassigned)

Tracking

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Avant Browser; Avant Browser; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5

I have created a recurring calendar item named 'New Item' lasting 1hr, two days in a week (Mon & Wed) from 09:00 til 10:00.
Then I copy the [first] item, select another day in the same week and paste it. At that point I obtain a additional item names 'null' covering 48hrs.

Copy-paste of a single, non-recurring item seems to work as advertised.

Reproducible: Always

Steps to Reproduce:
1. In the Calendar add a new event (Ctrl+I). I have used a free week to do the testing (e.g. Mon Jan 17, 2011).
2. Set the 'Start' and 'End' to the same day and with 1hr time span. set 'Repeat' to 'Custom...' and put the recurrence pattern to 'daily' every '2' days.
3. Set 'range of occurrences to 'Create'  and give '2' appointments.
4. Click 'OK' and next 'Save and Close'.
5. Highlight the first event and press Ctrl+C.
6. Highlight 'Tuesday' in the week.
7. Press Ctrl+V.
8. Highlight 'Wednesday' and press Ctrl+V.
9. Highlight the original second event (on Wednesday) and press Ctrl+C.
10. Highlight 'Tuesday' again and press Ctrl+V.
Actual Results:  
After 7. a new calendar item called 'null' is produced lasting 24hrs

After 8. a new calendar item called 'null' is produced lasting 48hrs

After 10. a new calendar item called 'null' is produced lasting 2hrs.

Expected Results:  
After 7. I would have expected 1 new item in the range called 'New Event' lasting 1hr. Same for 8. and 10.

Note: the reminder option (e.g. 5 mins) when creating the calendar item is *NOT* maintained.

Comment 1

7 years ago
Thanks for the detailed description.

I have just tried to reproduce this. However, it works perfectly for me.

Using Thunderbird 7 with Lightning 1.0b7

Comment 2

7 years ago
DutchGemini, can you still reproduce?

Can anybody else reproduce??
(Reporter)

Comment 3

7 years ago
Unfortunately I can't reproduce the problem anymore once I switched to 1.0b5 with TB6. After the upgrade, access to the calender server based on Sun Java Calendar Server I use at the office broke completely (can't login anymore, never occurred with 1.0b2). I am now bypassing this problem by using a web-interface.

However, I can confirm that the above instructions, with the given versions, are absolutely persistent.

Updated

7 years ago
Duplicate of this bug: 708957

Comment 5

7 years ago
I can reproduce it with trunk versions of both TB and Lightning under Linux. See duplicate bug 708957.

Comment 6

2 years ago
I can reproduce this easily with 4.0.5.2 by doing:

1. Create an event test with Repeat Bi-weekly until a date one month after the original.
2. Ctrl-X last 'test' event.
3. Ctrl-V one week after.

Result: A new "empty" event appears in the list of "All future events" with no name with a date that is not the one pasted into (or cut from). This event does not show up in the Calendar view.

Comment 7

2 years ago
Strangely, drag&drop seems to do the right thing.

Comment 8

a year ago
I can reproduce this in Ubuntu 14.04 with Thunderbird 52.2.1 (64 bits) and Lightning 5.4

1. Original event created on 20171020 that repeats itself everyday until 20171022 (3 days)

BEGIN:VEVENT
CREATED:20171019T172340Z
LAST-MODIFIED:20171019T172436Z
DTSTAMP:20171019T172436Z
UID:c81a5bd3-30b5-4d20-bdc3-33d1ef4532a7
SUMMARY:test 2 thun
ORGANIZER;RSVP=TRUE;CN=Usuari Ana;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:usua
 ri.ana@xxx.com
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:usuar
 i.elena2@xxx.com
ATTENDEE;RSVP=TRUE;CN=Al Solana;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT:mailto:AL.SOLANA@xxx.com
RRULE:FREQ=DAILY;UNTIL=20171022T070000Z
DTSTART;TZID=Europe/Madrid:20171020T090000
DTEND;TZID=Europe/Madrid:20171020T100000
TRANSP:OPAQUE
CLASS:PUBLIC
END:VEVENT


2. After copy/paste one day of previous event into 20171024 then two new events are created:

- A null event beginning on 20171024 and ending on 20171027, a 3 days long !!!

BEGIN:VEVENT
CREATED:20171019T173539Z
LAST-MODIFIED:20171019T173557Z
DTSTAMP:20171019T173557Z
UID:5cf7a199-c316-4a1a-a9d3-2f1d4b17b38e
RDATE;VALUE=DATE-TIME:20171024T070000Z
DTSTART;TZID=Europe/Madrid:20171024T090000
DTEND;TZID=Europe/Madrid:20171027T090000
X-MOZ-FAKED-MASTER:1
CLASS:PUBLIC
X-MOZ-GENERATION:1
END:VEVENT


- A new copy of original event into 20171024:

BEGIN:VEVENT
CREATED:20171019T173507Z
LAST-MODIFIED:20171019T173557Z
DTSTAMP:20171019T173557Z
UID:5cf7a199-c316-4a1a-a9d3-2f1d4b17b38e
SUMMARY:test copy thun
RECURRENCE-ID;TZID=Europe/Madrid:20171024T090000
ORGANIZER;RSVP=TRUE;CN=Usuari Ana;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:usua
 ri.ana@xxx.com
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:usuar
 i.elena2@xxx.com
ATTENDEE;RSVP=TRUE;CN=Al Solana;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT:mailto:AL.SOLANA@xxx.com
DTSTART;TZID=Europe/Madrid:20171024T090000
DTEND;TZID=Europe/Madrid:20171024T100000
CLASS:PUBLIC
END:VEVENT



It's a complete mess, Lightning is displaying the good new copied event, but the original webmail calendar displays only the null event. To fix the problem you must delete null and new copy event.

Comment 9

5 months ago
I can reproduce the error - although my concern is mainly with the wrongfully indication that this is a all-day event - in our company environment as well. TB 52.8.0 with Lightning version 5.4.8 but I’ve seen those problems also in earlier versions. So far I wasn’t able to get this error with non-recurring events, which I believe has to do with how Thunderbird copies recurring events. 


A few words on our setup: 
-------------------------
The company I work for uses a shared CALDAV calendar (Davical 1.1.7) for a couple of employees. This calendar contains both recurring and non-recurring events. Every employee has their own private calendar in addition to the shared calendar. This calendar is also stored on the Davical server. 


The following steps can be used to reproduce the problem:  
---------------------------------------------------------
There is a recurring event in the shared calendar that starts on a Wednesday and repeats every week. Now one colleague copies event from the second time it repeated and paste it to his private calendar. Now, not only is there just the one occurrence of the event in his calendar, but he is also shown as busy for the remainder of the day. (Check the invite attendee dialog of the lightning plugin) 

I activated the debug logging in the Davical installation and got the following ICS data for the PUT operation:  
(I added spaces so that I can read the content a bit better) 

=====================================================================================
BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0
BEGIN:VTIMEZONE 
TZID:Europe/Berlin 
BEGIN:DAYLIGHT 
TZOFFSETFROM:+0100 
TZOFFSETTO:+0200 
TZNAME:CEST 
DTSTART:19700329T020000 
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 
END:DAYLIGHT 
BEGIN:STANDARD 
TZOFFSETFROM:+0200 
TZOFFSETTO:+0100 
TZNAME:CET 
DTSTART:19701025T030000 
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 
END:STANDARD 
END:VTIMEZONE 
BEGIN:VEVENT 
CREATED:20180704T145536Z 
LAST-MODIFIED: 20180704T145536Z 
DTSTAMP:20180704T145536Z 
UID:76ac8ea4-b548-4ee4-8b61-0fa46e8e597e 
RDATE;VALUE=DATE-TIME:20180704T083000Z 
DTSTART;TZID=Europe/Berlin:20180704T103000 
DTEND;TZID=Europe/Berlin:20180704T103000 
X-MOZ-FAKED-MASTER:1 
END:VEVENT 
BEGIN:VEVENT 
CREATED:20180704T145419Z 
LAST-MODIFIED:20180704T145536Z 
DTSTAMP:20180704T145536Z 
UID:76ac8ea4-b548-4ee4-8b61-0fa46e8e597e 
SUMMARY:Besprechung
RECURRENCE-ID;TZID=Europe/Berlin:20180704T103000 
ORGANIZER;RSVP=TRUE;EMAIL=s.xxxxx@example.org;SENT-BY="mailto:j.xxxxxxxx@example.org ":mailto: s.xxxxx@example.org 
ATTENDEE;RSVP=TRUE;CN=Person XYZ;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:xxxxxxxxxxx@example.org 
DTSTART;TZID=Europe/Berlin:20180704T103000 
DTEND;TZID=Europe/Berlin:20180704T113000 
LOCATION:B4.17 
SEQUENCE:2 
TRANSP:OPAQUE 
X-MOZ-GENERATION:10 
X-MOZ-SEND-INVITATIONS-UNDISCLOSED:FALSE
X-MOZ-SEND-INVITATIONS:TRUE 
END:VEVENT 
END:VCALENDAR
=====================================================================================


The duration of the new FAKE MASTER event is not like the original event but DTSTART and DTEND is the same. I believe this is the reason why the event is identified as all-day event for at least the free busy part. 
In order to remove the Davical server from the possible reasons for the problem I performed the same steps within the emClient but the result was different. My test user was busy for just the duration of the event. 
The fake event does not have a Summary property which could be the reason for the null event. 
Maybe the problem would be solved if more information are copied into the fake master event. 

Please excuse my English. In case something isn’t clear, I’ll happily try to clarify it.

Comment 10

5 months ago
Can you please check whether this is still an issue in the current beta for TB60 (with Lightning 6.2) available from [1]? There have been implemented some improvements regarding c&p handling for the upcoming esr version.

[1] https://www.thunderbird.net/channel/
Flags: needinfo?(c.fluegel)

Comment 11

4 months ago
I installed the beta channel version (TB60.0b9 with Lightning 6.2) and carried out the above mentioned steps with another event from the shared calendar. I copied only a signle occurrence. 

The problem still exists and the test user is marked busy for the whole 24 period. I checked the ICAL content in the PUT request to the Davical Server and it looks pretty much identical. The DTSTART & DTEND of the fake master is still the same data. (I can post the content if it can help)
Flags: needinfo?(c.fluegel)
You need to log in before you can comment on or make changes to this bug.