Address book in Kolab admin webinterface: some entries not shown

Gunnar Wrobel wrobel at pardus.de
Thu Jan 22 07:35:03 CET 2009


Quoting Christian Rößler <Roessler at FuH-E.de>:

> Bernhard Reiter schrieb:
>
>> On Freitag, 16. Januar 2009, Christian Rößler wrote:
>>> <http://kartan.de/kolab/06_adressbuchverwaltung_keine_nummern.png>
>>> Changing the entry, numbers missing.
>>> Please let me know, if anybody can give me some hints. Of course I will
>>> give any needed information.
>> I can reproduce it here with 2.2.0,
>> so we'll follow up on it.
>
> Thanks again for that; this is very reassuring, if i may say so.
>
> I have noticed there is a bit of another issue, too. But for the  
> possibility that these things are related I will mention it for the  
> sake of completeness.
>
> When importing entries from elsewhere I notice the last character  
> from 'Vorname' entry (How it's called: Christian name? First name?)  
> missing - see appendes screen shots. (I know attachments are not  
> well received; but I made them very small).
>
> When looking into LDAP I notice in these entries that sn=cn:
>
> | kolab:~ # ldapsearch  -LLL -b cn=external,dc=kolab,dc=lokal,dc=de
> | cn="Alternate*" -h kolab
> | dn: cn=ALTERNATE Computerversand
> | GmbH,cn=external,dc=kolab,dc=lokal,dc=de
> | objectClass: top
> | objectClass: inetOrgPerson
> | objectClass: kolabInetOrgPerson
> | sn: ALTERNATE Computerversand GmbH
> | cn: ALTERNATE Computerversand GmbH
>
> If I make an entry with the kolab webfrontend this does not happen.  
> Difference, notice givenName:
>
> | kolab:~ # ldapsearch  -LLL -b cn=external,dc=kolab,dc=lokal,dc=de
> | cn="Vorname*" -h kolab
> | dn: cn=Vorname Nachname,cn=external,dc=kolab,dc=lokal,dc=de
> | objectClass: top
> | objectClass: inetOrgPerson
> | objectClass: kolabInetOrgPerson
> | sn: Nachname
> | cn: Vorname Nachname
> | givenName: Vorname
>
> If I add an entry 'givenName' to the first example above, nothing  
> changes. If I then enter the missing 'H' the entry shows correct; cn  
> gets automatically doubled. Can anyone give me a hint how this  
> behaviour can be circumvented? For example, if my data source just  
> has a CN and a SN (which I cannot change), should I better enter  
> sn->givenName and cn->sn, so Kolab constructs the cn?

These are known issues:

https://www.intevation.de/roundup/kolab/issue752
https://www.intevation.de/roundup/kolab/issue1000

The kolab webadmin does parse the cn entry to generate the givenName.  
This it does by taking the cn from position 1 to the length of the cn  
minus the length of sn *minus 1* (for the space to be expected between  
givenName and sn). Not a very good solution and it needs fixing at  
some point.

Cheers,

Gunnar

>
> Regards, Christian
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/users/attachments/20090122/2b1c128e/attachment.sig>


More information about the users mailing list