picky, picky. thanks.

Wouldn't it be the following?



RCS file: /repository/kronolith/fb.php,v

retrieving revision 1.32

diff -u -r1.32 fb.php

--- fb.php      19 May 2005 20:46:09 -0000      1.32

+++ fb.php      19 May 2005 22:52:50 -0000

@@ -41,7 +41,7 @@

          // to their username.

          if (!$cal) {

              $cal = $prefs->getValue('default_share');

-            if ($cal) {

+            if (!$cal) {

                  $cal = $user;

              }

          }

#2 implemented.

I should clarify - we came up with two mutually exclusive ideas...   
They aren't meant to be reconciled.

I had a discussion with my number #1 beta tester yesterday (my 
secretary :) and we came up with two ideas.



1)  Its better not to assume a share exists (by virtue of defaulting 
to a username if all else fails) than it is to return wrong FB info 
(assuming the user really wanted a different share or set of shares to 
be used).



2)  Its better to return potentially wrong FB info, than it is to 
require all users to set fb_cals in their Kronolith preferences so you 
don't have to worry about falling through to nothing and getting FB 
Not Found.



The percentage of users who will delete their primary share, and have 
multiple shares to choose from to generate FB info, but who would not 
set fb_cals, is probably very small.  So our thinking is that #2 is 
the way to go, which would be to default to their default_share and 
fall through to their username.  And if there was an initial 
maintenance task in Horde, fb_cal could be an item that was set during 
the first run (enhancement logged in ticket 2001).

We could try to load their default_share (we alread have the user's 
prefs object, as opposed to the current user's). Then if default_share 
is empty, default to the username?

Also, if you're not logged in, default_share is "0" :)



So maybe default_share isn't the place to fall back to.

Any clever ideas on how to handle cases where a user has not 
configured a fb_cal preference?  Or do we just assume that a user 
_must_ configure a default FB calendar?



I'd like to default it to their default _share.  But that doesn't work 
quite right, if they've never set their default share, because the 
default preference for that is Auth::getAuth() ? Auth::getAuth() : 0.   
If I'm logged in and I query FB info for userA, and userA has no 
fb_cal set (and assuming we drop back to look at default_share if 
fb_cal isn't set), no default_share set, then the preference for 
default_share becomes kevin_myer@iu13.org :(



I really need something along the lines of an Auth::getTheirAuth(), if 
I'm not retrieving prefs for myself.

Should be fixed now.

There's a cache namespace collision possible with my patch.  The FB 
info is cached with the username or calendar as the key (depending on 
if u or c is specified).  If I have a share named kevin_myer@iu13.org 
and I call fb.php with c=kevin_myer@iu13.org, the cache will contain 
FB info for a share.  If I shortly thereafter call fb.php with 
u=kevin_myer@iu13.org, and I have defined a different set of shares 
that should be used to generate my FB info (i.e. fb_cals is set to one 
or more shares), I'll get the cached results of just 
c=kevin_myer@iu13.org.



In other words, if fb_cals=kevin_myer@iu13.org and I call fb.php with 
either u, or c, I'll get the right results because u == c.



If fb_cals=kevin_myer@iu13,org, and another share 
(examplesharepadto32bits...), I'll get the wrong results from the 
cache, because u is actually c + exampleshare, but it will be cached 
with my email address as the key (and what results will be returned 
will depend on whether fb.php was called with u or c first).



Or maybe in plainer terms - my patch uses the same key for both user 
FB and single calendar FB info.  A simple solution would be to prepend 
a "u-" or a "c-" before the share/user name, so the cached result for 
u-kevin_myer@iu13.org would be my fb_cals FB info and the cached 
result for c-kevin_myer@iu13.org would be a share FB info.

So silly question, definitely outside the scope of this enhancement but...



Is there an easy way to get a diff of all the changes that were 
commited to CVS related to this patch?  You cleaned some of my hacking 
up and if I backport something, I want to track as closely as possible 
what was actually committed, instead of what I wrote.  I checked the 
CVS commit log mailing list but only found the one entry for fb.php 
and none for the supporting files.  I can always create a patch by 
piecing together the diffs from that date for the files that I know 
were changed but if there's an easier way to do it, I'd appreciate 
knowing it.



If not, having Chora be able to track the CVS commits (and generate a 
link to download a diff) related to a bug or enhancement would be a 
nice feature :)

Our general policy is to leave new features for new minor versions. 
There's a few other decent things in Kronolith 2.1, and with some work 
on the attendees/scheduling stuff, it'd be a solid minor release.

Any chance of having the bulk of this merged to the 2.0.X branch?  If 
not, I'll just maintain a local patch until 2.1 is "ready".

Committed for Kronolith 2.1, thanks!

Ok, here is a fixed version (also cleaned up to remove my site prefs.php).



This is all the previous patches rolled into one.  Remove the bits 
that make changes to the portions you don't want (i.e. My Calendars, 
and lib/Kronolith Free/Busy URL line).

Ugh - I now remember why I didn't submit this when I coded it up - I 
needed to add the preference lookup if a username argument was 
specified.  Fix to my fix coming up shortly :)

And if you could file as an enhancement and not a bug..  Need a second 
cup of coffee...

Guess it would help to actually attach the patch...

One minor thing that I missed - the actual VFB file contains a URL 
reference.  This is hardcoded to contain the c=shareid as the argument 
to fb.php.



This patch changes that behavior to use the u=username argument.



lib/Kronolith.php should probably return the URL that's used to 
generate the file, instead of hard-coding it one way or the other.  So 
maybe modifying the API for generateFreeBusy to include the URL as an 
argument as well...  I definitely can't change APIs, but I would think 
that adding another optional paremeter to generateFreeBusy would be 
pretty unobtrusive.

I'm keeping this separate from the preceeding patch.  This can be 
applied to change the functionality of "My Calendars" and have the 
user's FB URL be autogenerated and changed to the new username 
argument FB URL.  If, however, you have an installed base using FB 
URLs with the share ids and you need the ability to generate URLs with 
all those ids, you may not want to apply this.

This patch adds an argument to fb.php ("u") that will accept a 
username as an argument.  Result returned is the FB info for that 
user.  A new preference has been added ("fb_cals") that allows the 
user to select which of their available calenders they want to be 
included in generating FB info.  When the username is passed to 
fb.php, this preference is consulted to see which calendars to use.



This should be fully backwards compatible with existing functionality 
of fb.php, as it will still accept one or more share ids with the 
"c=shareid" arguments.