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