[kronolith] Fwd: freeBusyURL lookup based on login ID

[Kevin M. Myer]

> ----- Forwarded message from patrick.ni at redant.ca -----
>    Date: Sun, 02 Oct 2005 18:57:03 -0700
>    From: Patrick Ni <patrick.ni at redant.ca>
> Reply-To: Patrick Ni <patrick.ni at redant.ca>
> Subject: freeBusyURL lookup based on login ID
>      To: chuck at horde.org
>
> Hi Chuck,
>
> Upon reading horde/kronolith/lib/Kronolith.php, it seems that freeBusyURL is
> looked up from Turba Addressbook based on the "from" email address.
>
> I guess, I have to either add an address book entry for myself (which 
> is odd),
> or  add the "calFBURL" attribute at the address book base
> "ou=pni,ou=PAB,dc=redant,dc=ca", which requires me to tweak a little bit on
> this base entry for objectClass attributeS.

I don't remember if I saw this in the Wiki or come across a list, but I 
thought
I remembered seeing that suggestions were welcome for making the FB URL easier
to access, without requiring the setup of an Identity and having a calFBurl
entry somewhere.

What if the following was the search order?

1)  For all configured addressbooks, look for the user's FB URL, as mapped
through Turba's sources.  This will find FB URLs that have been published
explicitly (as part of account setup, in a user's local SQl address 
book, etc.)
2)  If nothing is found, try to retrieve a user's From: address from their
Identity.  This should find aliased accounts.
3)  If nothing is found, plug the email address directly into a URL of 
the local
Horde site (http://example.com/kronolith/fb.php?u=user@example.com).
4)  If nothing is found, error.

The FB URL, as it stands now, will follow the following search order:
A) If set, check the value of 'fb_cals'.
B) If no value is set for 'fb_cals', the value of 'default_share' will be
assumed.

People would still be encouraged to set FB URLs, because that would create a
match in step 1.  But if they didn't, the remaining searches should 
match a lot
of the cases that people would expect.

And maybe, for step 2, add a Horde setting for "What domains should be treated
as local?".  If the domain isn't in that setting,  step 2 and 3 could be
skipped and make the search more efficient.  The above comes with the 
potential
of building too much logic into the process, perhaps.

I don't know if I ever got around to mentioning it, but if B is used, and the
default_share is not originally owned by the user being queried (i.e.
supervisor sharing something with a secretary and secretary has supervisor's
share as default_share), potentially unwanted results are returned, 
because the
real owner's info and Identity info is returned.  Could a more reasonable
default be, instead of default_share, the share with the user's email address?

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org