Fri, 10 Apr 2026 09:21:00 +0000 https://bugs.horde.org/ticket/1683 Patch to generate static user FB URL 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. Mon, 04 Apr 2005 11:42:14 +0000 https://bugs.horde.org/ticket/1683#t6899 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. Mon, 04 Apr 2005 11:44:45 +0000 https://bugs.horde.org/ticket/1683#t6900 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. Mon, 04 Apr 2005 12:10:25 +0000 https://bugs.horde.org/ticket/1683#t6901 Guess it would help to actually attach the patch... Mon, 04 Apr 2005 12:11:23 +0000 https://bugs.horde.org/ticket/1683#t6902 And if you could file as an enhancement and not a bug.. Need a second cup of coffee... Mon, 04 Apr 2005 12:28:20 +0000 https://bugs.horde.org/ticket/1683#t6903 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 :) Mon, 04 Apr 2005 13:30:47 +0000 https://bugs.horde.org/ticket/1683#t6905 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). Mon, 04 Apr 2005 14:10:39 +0000 https://bugs.horde.org/ticket/1683#t6906 Committed for Kronolith 2.1, thanks! Sun, 10 Apr 2005 04:03:11 +0000 https://bugs.horde.org/ticket/1683#t7125 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". Wed, 13 Apr 2005 17:14:29 +0000 https://bugs.horde.org/ticket/1683#t7278 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. Wed, 13 Apr 2005 17:31:07 +0000 https://bugs.horde.org/ticket/1683#t7280 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 :) Thu, 21 Apr 2005 19:21:17 +0000 https://bugs.horde.org/ticket/1683#t7535 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. Thu, 12 May 2005 19:02:28 +0000 https://bugs.horde.org/ticket/1683#t8144 Should be fixed now. Thu, 12 May 2005 19:53:23 +0000 https://bugs.horde.org/ticket/1683#t8147 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. Wed, 18 May 2005 13:41:48 +0000 https://bugs.horde.org/ticket/1683#t8308 Also, if you're not logged in, default_share is "0" :) So maybe default_share isn't the place to fall back to. Wed, 18 May 2005 13:49:26 +0000 https://bugs.horde.org/ticket/1683#t8310 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? Thu, 19 May 2005 17:21:10 +0000 https://bugs.horde.org/ticket/1683#t8354 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). Thu, 19 May 2005 18:16:08 +0000 https://bugs.horde.org/ticket/1683#t8358 I should clarify - we came up with two mutually exclusive ideas... They aren't meant to be reconciled. Thu, 19 May 2005 18:19:00 +0000 https://bugs.horde.org/ticket/1683#t8359 #2 implemented. Thu, 19 May 2005 20:46:30 +0000 https://bugs.horde.org/ticket/1683#t8367 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; } } Thu, 19 May 2005 22:56:19 +0000 https://bugs.horde.org/ticket/1683#t8372 picky, picky. thanks. Fri, 20 May 2005 00:28:38 +0000 https://bugs.horde.org/ticket/1683#t8374