Closed
Bug 421329
Opened 16 years ago
Closed 15 years ago
Freebusy information is not loaded for multiday events beginning previous to look-up date
Categories
(Calendar :: General, defect)
Calendar
General
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b1
People
(Reporter: pgoerzen, Assigned: lmarcotte)
Details
Attachments
(2 files, 1 obsolete file)
1.69 KB,
patch
|
Details | Diff | Splinter Review | |
730 bytes,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1) Build Identifier: Thunderbird (Icedove) 2.0.0.9 (20080128) / Lightning 0.7 I have a multi-day event beginning March 8 and ending March 15 and mark it as busy. I create another event and view freebusy information. If the event is on or before March 8, the the entire block is marked busy. However, if the new event is after March 8, the multi-day block is marked free. Reproducible: Always Steps to Reproduce: 1. Create a multi-day event, and mark it busy. 2. Create another event after the start day of the multi-day event but before the end day. 3. Go to invite attendees. Actual Results: Time for multi-day event is not marked busy. Expected Results: Time should be marked busy. I'm using eGroupWare, which publishes freebusy information for this event (which crosses DST boundary) as follows: FREEBUSY:20080308T060000Z/20080316T045959Z Testing with 0.7, but this doesn't appear to be fixed in 0.8 yet either.
Reporter | ||
Comment 1•16 years ago
|
||
Haven't tested with Lightning 0.8. 0.7 works, but I'm very new to the Lightning code ;-) Checked "regular," all-day, and multi-day events before, during, and after the event and across the U.S. March DST change (couldn't check Nov. due to server settings).
Comment 2•16 years ago
|
||
Comment on attachment 307812 [details] [diff] [review] Possible patch for the bug This patch has been lying around for two month. I don't know if the patch is useful, and who might be an appropriate reviewer. Asking Daniel, and he can delegate the review. ;)
Attachment #307812 -
Flags: review?(daniel.boelzle)
Updated•16 years ago
|
Assignee: nobody → pgoerzen
OS: Linux → All
Hardware: PC → All
Comment 3•16 years ago
|
||
I checked this issue with lightning build 2008081018 on a Bedework caldav server and it works form me. The multi-day event is marked busy in the invite attendees dialog.
Comment 4•16 years ago
|
||
Peter, could you please retest this issue with a recent nightly build? Thanks!
Comment 5•16 years ago
|
||
Comment on attachment 307812 [details] [diff] [review] Possible patch for the bug Removing me from review until I could confirmed the issue.
Attachment #307812 -
Flags: review?(daniel.boelzle)
Reporter | ||
Comment 6•16 years ago
|
||
(In reply to comment #4) > Peter, could you please retest this issue with a recent nightly build? Thanks! > I use the SoGo connector to do freebusy with my eGroupWare server. Unfortunately, the API has changed enough in 0.9 that the connector doesn't work with it. I'll test again as soon as I can install a different CalDAV test server or modify the plugin or eGroupWare to work with 0.9. Sorry for the delay.
Assignee | ||
Comment 7•15 years ago
|
||
The bug is still present in Lightning 0.9 and is not related to DST changes.
Assignee | ||
Comment 8•15 years ago
|
||
Updated•15 years ago
|
Attachment #354832 -
Attachment is patch: true
Attachment #354832 -
Attachment mime type: application/octet-stream → text/plain
Updated•15 years ago
|
Attachment #307812 -
Attachment is obsolete: true
Comment 9•15 years ago
|
||
Ludovic, if it's not related to DST changes, but reproducable for you, could you give some insight about the bug and patch?
Assignee | ||
Comment 10•15 years ago
|
||
(In reply to comment #9) > Ludovic, if it's not related to DST changes, but reproducable for you, could > you give some insight about the bug and patch? Comment #0 gave a perfect example but here is one again. Say you have an event that starts on January 10th and ends on January 15th. Do a freebusy lookup on yourself on January 13th. It'll fail as the event's start date is earlier than the lookup's start date so it'll be ignored and thus, you'll be shown as 'free'. I did all my testing with SOGo / CalDAV and the freebusy info _is returned_ correctly.
Updated•15 years ago
|
Summary: Freebusy info. not loaded for multi-day events beginning previous to lookup date → Freebusy information is not loaded for multiday events beginning previous to look-up date
Assignee | ||
Comment 11•15 years ago
|
||
Proposed fix for comment #10
Attachment #363584 -
Flags: review?(philipp)
Updated•15 years ago
|
Attachment #363584 -
Flags: review?(philipp) → review+
Comment 12•15 years ago
|
||
Comment on attachment 363584 [details] [diff] [review] Proposed fix Makes sense, r=philipp
Comment 13•15 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/5849add3d24f> -> FIXED
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Keywords: qawanted
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Comment 14•15 years ago
|
||
Comment on attachment 363584 [details] [diff] [review] Proposed fix >--- calendar-event-dialog-freebusy.xml.original 2009-02-22 12:40:23.000000000 -0500 >+++ calendar-event-dialog-freebusy.xml 2009-02-22 12:45:20.000000000 -0500 >@@ -811,6 +811,13 @@ > let rangeStart = entry.interval.start.getInTimezone(kDefaultTimezone); > let rangeEnd = entry.interval.end.getInTimezone(kDefaultTimezone); > >+ if (rangeStart.compare(start) < 0) { >+ rangeStart = start.clone(); >+ } >+ if (rangeEnd.compare(end) > 0) { >+ rangeEnd = end.clone(); >+ } >+ > if (rangeStart.compare(start) >= 0 && > rangeEnd.compare(end) <= 0) { Looks like the follow-on range check is obsolete here.
Comment 15•13 years ago
|
||
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•