[Tickets #6903] Re: Silence warning on creation/update of a Kolab object

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/6903
------------------------------------------------------------------------------
  Ticket             | 6903
  Updated By         | Gunnar Wrobel <p at rdus.de>
  Summary            | Silence warning on creation/update of a Kolab object
  Queue              | Horde Framework Packages
  Version            | FRAMEWORK_3
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Gunnar Wrobel
------------------------------------------------------------------------------


Gunnar Wrobel <p at rdus.de> (2008-07-02 03:41) wrote:

>>> Auth::getAuth() is defined as "user id". I'm not sure if it always
>>> must contain an @domain part.
>>
>> Are you using the Auth::kolab driver then? The kolab driver should
>> rewrite the user id to the primary mail adress (see the setAuth()
>> function in that driver). It looks like you are using UIDs in your
>> system. At least in former times that was problematic for other Horde
>> subsystems and that is why the kolab driver does the rewrite. I admit
>> I don't remember exactly what the effects of using a UID were. But my
>> gut feeling is that even with our new infrastructure it makes more
>> sense to use the primary Kolab ID.
>
> I'm using IMP as Auth backend, which authenticates against an IMAP server.

Ah, now I understand.

>
> Everything works fine, no complaints from the users so far. If some
> part of the Kolab subsystem does work only with the Kolab Auth
> backend,
> then it needs fixing :-)

Yes, true.

>
> I'll have an idea that satisfies both your needs: Why not check the
> From: and To: address for the "@" character and append "@localhost"
> only if it is not found?

As this is just the mail address in the object I guess it could be  
done that way. But it feels little bit too much like a hack to me.  
Especially since we should have the possibility to retrieve the users  
primary mail address from LDAP on any reasonable Kolab server.

This is what I implemented in the new framework now. The Session  
handler was fetching the Kolab user object anyhow, so retrieving and  
storing the primary mail was just a small addon. I added your solution  
in the session handler as a last backup in case querying the LDAP  
server didn't help.

The session handler caches the primary mail address so it should not  
slow down the writing of Kolab messages to IMAP by first querying LDAP.

>
> Thomas
>