Recurring all day event -> duplicate event created after editing a single all day event

VERIFIED FIXED in 1.0b1

Status

Calendar
Provider: Local Storage
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: fif4183, Assigned: Fallen)

Tracking

unspecified
1.0b1
Bug Flags:
blocking-calendar1.0 +

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(4 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Opera/9.52 (Windows NT 5.1; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Calendar/1.0pre

If a single instance of an all day weekly-repeating event is edited, the original unedited event reappears adjacent to the modified event the next time the user opens the calendar program, Sunbird in this case.

Reproducible: Always

Steps to Reproduce:
1. Create a new All Day Event that repeats weekly
2. Edit a single occurrence of the event
3. Change the description of the specified single event and save
4. Exit the application, Sunbird in this case
5. Open the application
6. Upon loading, the application shows both the edited event and the original event on the same day.
<br>
<img src="http://www.stotera.com/images/Clipboard01.jpg"><br>
<img src="http://www.stoera.com/images/Clipboard02.jpg"><br>
Actual Results:  
Two events shown.

Expected Results:  
One event shown (the edited one).

This problem did not exist in Sunbird 0.7, but it does exist in Sunbird 0.9 and Sunbird 1.0pre.
(Reporter)

Comment 1

9 years ago
Created attachment 352322 [details]
Image showing steps 1 through 5 of reproducing the issue
(Reporter)

Comment 2

9 years ago
Created attachment 352323 [details]
Image showing step 6 to reproduce the issue

Comment 3

9 years ago
It's possible for me to reproduce this issue with lightning build 20081210 and a local storage calendar.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-calendar1.0?
OS: Windows XP → All
Hardware: PC → All
Flags: wanted-calendar1.0? → blocking-calendar1.0?
(Reporter)

Comment 4

9 years ago
I'm not sure whom this bug should be assigned to.

However, I just remembered an issue I had with Sunbird 0.8.  If I made a repeating event but I later tried to edit just one instance, it was necessary to make the change twice.  The first time, it did not store the change.

This seems like it may be related to bug 468846, but I'm not sure who worked on it previously.

Updated

9 years ago
Duplicate of this bug: 471266
(Assignee)

Comment 6

9 years ago
Confirmed. This sucks. blocking+
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Created attachment 370004 [details] [diff] [review]
[checked in] fix - v1

This fixes the problem. Storage has always handled RECURRENCE-ID as DATE-TIME.

BTW: I couldn't run the unit tests; is that issue known (or my build broken)?

/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python: can't open file '/Users/dbo/moz_cc/src/mozilla/testing/xpcshell/runxpcshelltests.py': [Errno 2] No such file or directory
make: *** [check] Error 2
Assignee: nobody → dbo.moz
Status: NEW → ASSIGNED
Attachment #370004 - Flags: review?(philipp)

Comment 8

8 years ago
(In reply to comment #7)
> BTW: I couldn't run the unit tests; is that issue known (or my build broken)?
> .../src/mozilla/testing/xpcshell/runxpcshelltests.py': [Errno 2]

|make check| runs fine for me on win32 sunbird build as of today.
(Assignee)

Comment 9

8 years ago
Comment on attachment 370004 [details] [diff] [review]
[checked in] fix - v1

r=philipp, thanks a bunch!
Attachment #370004 - Flags: review?(philipp) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/dd1eb3b7a752>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0

Updated

8 years ago
Component: General → Provider: Local Storage
QA Contact: general → storage-provider

Comment 11

8 years ago
The patch that was committed will not work if you have a DATE-TIME based recurring meeting which has one DATE-ONLY exception, the recurrence id for the exception must have the time information even if the exception instance is an allday event.

- Create a DAILY recurring for 3 days
- Make second instance an all day event
- Restart, observe duplicate instance

Here is a suggested workaround that seems to work for me (but will not work if the original instance has a time value of T000000. But it's still better than the current situation.

            // If the item is of type "allday" and
            // no "time" values are specified, assume that the 
            // recurrenceId is a date type value
            if ((row.flags & CAL_ITEM_FLAG_EVENT_ALLDAY) != 0 &&
                item.recurrenceId.hour == 0 &&
                item.recurrenceId.minute == 0 &&
                item.recurrenceId.second == 0) {
              item.recurrenceId.isDate = true;
            }
(Assignee)

Updated

8 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Philipp, is this [needed beta]?
(Assignee)

Comment 13

8 years ago
If possible we should fix this for the beta, but I'd be fine postponing it to beta2.

I think the better solution would be to add a column so that also instances with T000000 work.
Whiteboard: [needed beta][no l10n impact]
Status: REOPENED → ASSIGNED
Attachment #370004 - Attachment description: fix - v1 → [checked in] fix - v1
I agree with Philipp that the easiest solution would be to add a flag, e.g. CAL_ITEM_FLAG_PARENT_ALLDAY), so overridden items construct the correct recurrence id value type.
(Assignee)

Comment 15

8 years ago
Created attachment 395429 [details] [diff] [review]
Fix - v2

This fixes, requires patch from bug 470430 and possibly also from bug 494140 (the latter of which I only have local, since I don't know how much more 470430 will change. Ask me if needed).
Assignee: dbo.moz → philipp
Attachment #395429 - Flags: review?(dbo.moz)

Updated

8 years ago
Depends on: 470430
(Assignee)

Updated

8 years ago
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]
Comment on attachment 395429 [details] [diff] [review]
Fix - v2

The patch looks good.

>+    ALLDAY_OCCURRENCE: 512
I think this wording is misleading, because
1. The occurrence itself already has EVENT_ALLDAY.
2. It's a flag to just balance out the RECURRENCE-ID which relates to the parent item's rule.

That way I'd propose to make clear what type the parent has (allday or not), e.g. PARENT_IS_ALLDAY or the like.

r=dbo with this resolved
Attachment #395429 - Flags: review?(dbo.moz) → review+
(Assignee)

Comment 17

8 years ago
At first I thought this wasn't quite true, but actually you are right. To be even more clear, I think we should call it RECURRENCE_ID_ALLDAY. This way all ambiguities should be taken care of.

I'll check this in as soon as bug 470430 and bug 494140 are checked in.
(Assignee)

Updated

8 years ago
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact][waiting bug 470430/494140]
(Assignee)

Comment 18

8 years ago
bug 470430 is sufficient for applying this patch. I will check this in tomorrow when we have a nightly with the aforementioned bug.
Whiteboard: [needed beta][no l10n impact][waiting bug 470430/494140] → [needed beta][no l10n impact][waiting bug 470430]
(Assignee)

Comment 19

8 years ago
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/d415929fcd61>
and <http://hg.mozilla.org/releases/comm-1.9.1/rev/5a2b419e72f9>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
Whiteboard: [needed beta][no l10n impact][waiting bug 470430] → [needed beta][no l10n impact]
(Assignee)

Comment 20

8 years ago
Comment #17 taken into account in revs c-c: a2514ada730a c191: 7fee9d989390

Comment 21

7 years ago
verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10pre) Gecko/20100323 Calendar/1.0b2pre
Status: RESOLVED → VERIFIED

Updated

7 years ago
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.