Closed Bug 468846 Opened 16 years ago Closed 15 years ago

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

Categories

(Calendar :: Provider: Local Storage, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: fif4183, Assigned: Fallen)

References

Details

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

Attachments

(4 files)

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.
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?
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.
Confirmed. This sucks. blocking+
Flags: blocking-calendar1.0? → blocking-calendar1.0+
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)
(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.
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
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Component: General → Provider: Local Storage
QA Contact: general → storage-provider
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;
            }
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Philipp, is this [needed beta]?
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.
Attached patch Fix - v2Splinter Review
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)
Depends on: 470430
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+
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.
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact][waiting bug 470430/494140]
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]
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
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Whiteboard: [needed beta][no l10n impact][waiting bug 470430] → [needed beta][no l10n impact]
Comment #17 taken into account in revs c-c: a2514ada730a c191: 7fee9d989390
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
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.