[Tickets #5576] free/busy information takes wrong owner information as identity

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=5576
-----------------------------------------------------------------------
 Ticket             | 5576
 Created By         | tim.vanholder at anubex.com
 Summary            | free/busy information takes wrong owner information as identity
 Queue              | Kronolith
 Version            | 2.1.4
 Type               | Bug
 State              | Unconfirmed
 Priority           | 2. Medium
 Owners             | 
-----------------------------------------------------------------------


tim.vanholder at anubex.com (2007-07-24 07:18) wrote:

(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.