6.0.0-beta1
8/9/25

[#5576] free/busy information takes wrong owner information as identity
Summary free/busy information takes wrong owner information as identity
Queue Kronolith
Queue Version 2.1.4
Type Bug
State Resolved
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester tim.vanholder (at) anubex (dot) com
Created 07/24/2007 (6591 days ago)
Due
Updated 07/31/2007 (6584 days ago)
Assigned
Resolved 07/31/2007 (6584 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
07/31/2007 03:37:05 PM Chuck Hagenbuch Comment #2
Assigned to Jan Schneider
State ⇒ Resolved
Reply to this comment
07/24/2007 02:18:07 PM tim (dot) vanholder (at) anubex (dot) com Comment #1
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ free/busy information takes wrong owner information as identity
Queue ⇒ Kronolith
Reply to this comment
(Using 2.1.4 because that's the version debian provides)



The free/busy information produced by fb.php, as well as the default 
required attendee added when creating an event, tries to deduce the 
identity of the involved person using only calendars. However, this 
behaviour is broken.

The information is taken from the fb_cals preference; the first of the 
calendars in that list is taken, and its owner is used as the identity 
behind the f/b info. However, fb_cals is lexically sorted on its 
display name, which in our case causes the company-wide shared 
calendar (owned by our HR person) to be that identity.

So everyone's f/b url returns that HR person's name and email, and the 
attendee list shows the HR person in the f/b diagram for every 
attendee (mails are still sent to the correct address however).



I hacked around it by specifically skipping our shared calendar in 
Kronolith.php, but that's a kludge (other shared calendars could crop 
up resulting in similar problems). A more general solution is needed 
to truly fix this.



As I understand it, the Horde user is always known when generating 
free/busy info in attendees.php and  fb.php, except for when c= is 
given instead of u=; so let the current 
get-user-identity-from-calendar behaviour only apply in that case, and 
things should work better. I assume that simply adding a $user 
parameter (or similar) to Kronolith::generateFreeBusy() should do the 
trick, with a null $user causing the current behaviour.


Saved Queries