[Kolab-devel] freebusy CVS observation + questions

[Mike Gabriel]

hi gunnar,

> > a little above the quoted section, there is a comment that states:
> >
> > <quote>
> >   // IMAP path is either /INBOX/<path>@domain or
> >   // /user/someone/<path>@domain strip domain
> > </quote>
> >
> > unfortunately, this is not true on my kolab/horde install (kolab-2.1
> > with horde-webmail-1.1.rc1).
> >
> > there is no domain component in the folder path on my kolab/horde
> > install!!! if it was, we would be lucky,  we could strip off the
> > domain and keep it for rendering an unequivocal, unique fb-update URL.
> > we cannot use some kind of default domain here with kolab's virtual
> > domain support.
>
> I'm not certain I understand why you deactivated this. Is this
> required for your setup? Any chance of activating it?

i only deactivated the relevance patch because it blocked freebusy generation 
on my system ("Folder INBOX/Kalender is irrelevant for <mail-of-cal-owner>", 
refer to my other mail). i did not change anything in triggerFreeBusyUpdate.

i think, there is a misunderstanding here: my cyrus folders all look fine:

   /user/<someone>/<path>@<domain>

but the domain part does not survive till it reaches share_uid in 
triggerFreeBusyUpdate (it is stripped before it reaches triggerFreeBusyUpdate 
to /user/<someone>/<path>.

> > maybe you have a clue, how to derive a mailuser's domain from the
> > share_uid if the domain name is not part of the share_uid... where is
> > the domain name stripped of the share_uid in horde's Kolab driver??? i
> > could not find that...
>
> The share_uid is based on the folder name so I don't expect this to
> have a domain suffix either. But you are running with a single domain
> then? It should be possible to use a default domain setting then. We'd
> need to add the required code for that though.

i use multiple email domains, so a standard value is not really a solution 
(for other kolab-setups, i suppose, multiple domains will be the common case, 
as well). so a standard value for the domain is not really applicable, to my 
point of view. but of course, it can be a workaround...

unfortunately, to my mind you cannot map the contents of share_uid 
("user/somename/somecalendar") back to the full/primary mail-adress as stored 
in kolab's LDAP-server (and this is what you need to call pfb.php of your new 
freebusy engine). if a user changes anything in an event folder that is not 
owned by this user, you need the domain component of the cyrus-mailpath.

but the domain part of the mail adress gets lost on its way to 
triggerFreeBusyUpdate(). i thought of addressing "somename" in share_uid as 
the LDAP uid attribute and ask LDAP for the mail attribute, but this only 
applies to the conventions on my kolab setup, it will neither meet 
requirement of any common case... (the common case will be <uid>@<domain> != 
<mail>).

BUT, THIS MIGHT SAVE THE DAY
----------------------------
there is another issue in this context that appeared to me.

it does not seem possible to ACL-share cyrus folders if two people belong to 
two different virtual kolab domains. example:

  m.gabriel at sunweavers.net

cannot access shares of 

  m.gabriel at moonweavers.net

at least not in horde, the ACLs are simply dropped when i set them. i haven't 
checked other kolab clients, but if this is intended, we are pretty fine with 
the above issue!!!

then we can grab the <domain> part from Auth:getAuth of the authenticated 
horde user and trigger free busy update of other folders not owned by the 
authenticated user. if only access to share within the same domain is 
possible, than the other persons calendar folder must be in the same domain 
as the authenticated user is.

hope you understand my babble...
mike




-- 

+++ das-netzwerkteam.de +++

mike gabriel, hamburger chaussee 240, 24113 kiel
fon: +49 431 64-74-196
fax: +49 431 64-74-276
voip/voicemail: +49 431 643 643 6
mail: m.gabriel at das-netzwerkteam.de
www: http://das-netzwerkteam.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080221/1ab2febf/attachment.sig>