6.0.0-RC7
6/27/26

[#4290] Recuring (not-full-day) events seems to break FreeBusy
Summary Recuring (not-full-day) events seems to break FreeBusy
Queue Kronolith
Queue Version 2.1.2
Type Bug
State Resolved
Priority 2. Medium
Owners Horde Developers (at)
Requester horde (at) addelei (dot) nu
Created 8/14/06 (7257 days ago)
Due
Updated 9/22/06 (7218 days ago)
Assigned 8/20/06 (7251 days ago)
Resolved 9/22/06 (7218 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
93 Chuck Hagenbuch Comment #2
State ⇒ Resolved
Reply to this comment
Fixed in CVS and FW_3.
511 Chuck Hagenbuch Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
 
5912 horde (at) addelei (dot) nu Comment #1
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Recuring (not-full-day) events seems to break FreeBusy
Queue ⇒ Kronolith
New Attachment: event.ics Download
Reply to this comment
Adding a recurring event, in this case a one-hour event each day from 
August 14:th to August 18:th, seems to break Freebusy by completely 
filling the person's calendar.



Looking at the code, it seems that the startdate on recurring events 
returned by Kronolith::listEvents (called in lib/Kronolith.php at line 
822*) is set to the last day after the recursion end, while enddate is 
set to the original end date (as set in the calendar). This makes 
$duration (lib/Kronolith.php, line 852) negative - effectively filling 
the calendar.



For debugging, I've added the following right after the calculation if 
$duration:

<code>

if ($duration < 0) print_r($event);

</code>



With the attached event.ics file, I get five Kronolith_Event_sql 
objects, one for each day the event is recurring (the $day variable, 
line 846, is correctly set). On each object, the $start property is 
2006-08-19 while the $end property is 2006-08-14. Based on the 
following code (including the comment "Make sure that we're using the 
current date for recurring events", I would guess that the $start 
property should have been 2006-08-14 instead.



I've tried to trace the error backwards to Kronolith::listEvents, but 
I seem to get lost in the code.



* All line numbers might be slightly off since I've been adding and 
removing lines consisting of debug-related print_r()'s!

Saved Queries