atom feed5 messages in org.kde.kde-pimRe: Problem with Free/Busy in Kontact...
FromSent OnAttachments
Bo ThorsenSep 21, 2004 2:49 am.diff
Andreas GunglSep 21, 2004 2:57 am 
Bo ThorsenSep 21, 2004 4:07 am 
Andreas GunglSep 21, 2004 11:07 pm 
Martin KonoldSep 22, 2004 1:29 pm 
Subject:Re: Problem with Free/Busy in Kontact HEAD with Kolab 1
From:Bo Thorsen (bo@sonofthor.dk)
Date:Sep 21, 2004 4:07:14 am
List:org.kde.kde-pim

On Tuesday 21 September 2004 11:57, Andreas Gungl wrote:

Am Dienstag, 21. September 2004 11:49 schrieb Bo Thorsen:

Jeopardy quoting, sorry.

Andreas, you are hit by the check in KOrganizer that makes sure you can only download free/busy lists from a server that matches the domain of the email address you have. In this case, you try to download the fb list of gun@osp-dd.de from dre.osp-dd.de, and the domains doesn't match.

I'm not sure I understand correctly. For my understanding, osp-dd.de is the domain while dre.osp-dd.de is the host providing the Kolab server/services for domain osp-dd.de. I thought, the guess of machine dre being part of domain osp-dd.de is valid.

The code the patch uncomments makes a string comparison of the email domain with the server domain. And "osp-dd.de != dre.osp.dd.de". That's why it fails. The test could be patched up by checking with:

if(email == domain || email.endswith(domain) || domain.endsWith(email))

That would make a bit more sense, but the more general problem remains.

Nevertheless, I think you know better than me what we're talking about. Andreas

Dangerous assumption :-)

Bo.

I have tried getting the attached patch into kdepim, but so far unsuccesful. It just disables the check, so you try and download all freebusy from the server.

Pim people: You receive this mail, because as you can now see, the current behaviour hurts some users. We need a solution for it. Proposed solutions:

- whitelisting domains - make a protocol so the server can tell what domains it can server - make a checkbox to perform the check that the patch removes or not

The catch-all fix could be to have a checkbox to just always try and download fb lists from the server, and if this is not checked, a whitelist of domains the server can give can be used.

Of course, an FB list setting in a contact should always override this.

Bo.

On Tuesday 21 September 2004 10:33, Andreas Gungl wrote:

Am Dienstag, 21. September 2004 09:29 schrieb Bo Thorsen:

On Tuesday 21 September 2004 09:08, Andreas Gungl wrote:

I'm doing some tests to prepare a switch from Kolab 1 to Kolab 2 and to introduce Kontact as complete Kolab client. However I have problems with handling the free/busy information. Uploading the files works fine and I can see the files on the server using Konqueror and the webdav protocoll. I can follow the uploading of the files as well in the Apache access log on the Kolab server.

However downloading free/busy information doesn't work. I can download files using Konqueror, but KOrganizer gives me the following output:

---------------------------------------- korganizer: KOEditorFreeBusy::reload() korganizer: FreeBusyManager::retrieveFreeBusy(): gun@osp-dd.de kabc: StdAddressBook::self() korganizer: FreeBusyManager::loadFreeBusy(): gun@osp-dd.de korganizer: FreeBusyManager::loadFreeBusy() /home/domino/.kde/share/apps/korganizer/freebusy/gungl@osp-dd.d e.if b doesn't exist. korganizer: FreeBusyManager::retrieveFreeBusy(): url: korganizer: Invalid FB URL

----------------------------------------

I have configured the sane protocoll, server and user for retrieving the free/busy information as for publishing. I have tested with checked and unchecked option "use full email address for retrieval".

Can anyone give a comment on what might be wrong? BTW, I'm using a kde-pim CVS snapshot from yesterday.

What is the server domain? What did you put in the lineedits of the freebusy setup? Do you have an FB setting on this person in the kaddressbook entry or in the FB location setup of korganizer? And what URL do you use for accessing the FB list with konqueror?

Here we go:

On the publishing side:

General = Publish is checked, publish 60 days and min. 5 min between uploads Server URL = webdav://dre.osp-dd.de/freebusy/gungl%40osp-dd.de.ifb Username = gun@osp-dd.de PW = **** ;-)

On the retrieving side:

General = "Retrieve others ... automatically " is checked, "use full ..." doesn't matter if checked or not Server URL = webdav://dre.osp-dd.de/freebusy/ Username = must@osp-dd.de PW = **** ;-)

In Konqueror:

URL = webdav://dre.osp-dd.de/freebusy/ Files showing up = gun@osp-dd.de.ifb must@osp-dd.de.ifb Both files are readable from within Konqueror, I can even modify them by opening them in KWrite.

I don't know about another location setting in KOrganizer than the fields mentioned above, sorry. Important: the person gun@osp-dd.de is _not_ in the addressbook, so it doesn't have a FB URL set there. LDAP access however is configured, i.e. I can see the person from within KMail and KOrganizer.

The problem is that somehow the code decides to check locally instead of on the server, as you can see from the filename it tries to get. The question is, of course, why it would think this is the right place.

Best guess: You have a different server domain than the email address you are trying to obtain the ifb file for.

Further observations I did after stumbling across your hint regarding the FB setting in the addressbook, are:

- Having the user in the addressbook without FB setting changes nothing. I.e. the FB download fails.

- Having the user in the addressbook _with_ FB setting allows the retrieval of the FB file. (I used webdav://dre.osp-dd.de/freebusy/gungl%40osp-dd.de.ifb for my example above.)

- Collecting an address from LDAP into my addressbook seems to provide the FB URL only for people which do have FB information uploaded. I write "seems" because I cannot really verify this. At least it works this way here.

Well, let me finally summarize my expectations how it should work: - FB retrieval should work without FB setting in the addressbook by using the default URL set in KOrganizer. - FB settings in LDAP actually shouldn't be made automatically but only intentionally in the frontend. Only this way one can be sure to have consistent information when copying contacts from LDAP into the addressbook. This would also avoid unintended overriding of the default URL in KOrganizer by using any other LDAP server.

Regards, Andreas