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 |
Assigned to Jan Schneider
State ⇒ Resolved
http://cvs.horde.org/co.php?r=1.7&f=kronolith%2Flib%2FFreeBusy.php
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ free/busy information takes wrong owner information as identity
Queue ⇒ Kronolith
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.