freebusy with kolab debian packages

[Mike Gabriel]

hi gunnar,

Quoting Gunnar Wrobel <wrobel at pardus.de>:

> Hi Mike,
>
> Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
>
> [...]
>
> What horde does within the call "triggerFreeBusyUpdate" (currently in
> Kolab.php -> on my systems /usr/share/php/Horde/Kolab.php) is to
> trigger using the URL
>
> 'https://' . Kolab::getServer("imap") . '/freebusy/trigger/' .  
> $folder . '.xpfb'

arggghhh... i used "localhost" as imap server string. however, my  
apache has a vhost setup and "localhost" is very much different from  
"mail.mydomain.de".

wouldn't it be better to address horde's $conf['server']['name'] here?  
(ah no, forget this, horde-webserver and imap-server can be on  
different hosts... hmmm... maybe a config parameter for the freebusy  
URL is needed in kronolith's conf.php?


> Anyhow if that triggering URL works on your system, Horde should
> trigger the update.

with the new hostname for the imapserver and a fix in Cache.php it now works:

FIX for Cache.php/CVS: in FreeBusyCache::&loadPartial you set  
$fbfilename in the first line, but then refer to $file in the rest of  
the method. i have replaced any occurence of $file by $fbfilename and  
also commented out the check for relevance (my kronolith has the  
patches in kolab-2.2-CVS, including the relevance patch). with these  
changes the fb cache generation now works.

>>   o i tried to authenticate against freebusy/trigger with my kolab/LDAP
>>     systems calendar user, but the freebusy/trigger https authentication
>>     failed
>
> Yes, you can only use the users credentials that OWNs the folder.

ok, got that. fb-cache is updated after every call of "saveEvent" in  
horde, i suppose that other kolab clients behave similarly... now it  
is clear, why an authenticated user is the normal case for  
fb-generation...

> Shared folders are not taken into account when it comes to the
> calculation of free/busy times. I'm not 100% certain if this was
> intended this way but I believe it makes sense. Shared folders usually
> contain very generic events. Image a situation where you have a shared
> folder accessible to all users on your system: Add one event and
> suddenly all your users are blocked by this event.

ok, agreed. how about groups, would they work and be include in  
freebusy information???

i now have a further problem.

in my lib/Horde/iCalendar/vfreebusy.php (horde-3.2-rc1)  
Horde_iCalendar_vfreebusy::getName() does not return a valid friendly  
name for the ORGANIZER. this probably is mainly due to a missing CN  
param for the ORGANIZER in my freebusy cache files generated by the  
kolab-2.2 freebusy engine (i backported fb scripts from kolab-2.2 to  
kolab-2.1).

is it intended that the ORGANIZER's CN is missing in the vcal files?

fragen über fragen,
mike



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.