uid regeneration

[Michael]

I tried importing my old kolab 2 ldap to some kolab 3 test installation.
With my old kolab the uid is the primary mail address, which is bound to some nickname or initials or whatever. Specifically _not_ the sn.

As an example, if my domain would be example.com and some users name would be Richard M. Stallman, his uid would be rms at example.com:
dn: cn=Richard Stallman,dc=example,dc=com
sn: Stallman
cn: Richard Stallman
givenName: Richard
mail: rms at example.com
uid: rms at example.com

That's not ok with kolab 3 where the uid is part of the dn. So I manually edited it to the following before importing:
dn: uid=rms,ou=People,dc=example,dc=com
sn: Stallman
cn: Richard Stallman
givenName: Richard
mail: rms at example.com
uid: rms
(that's ok to do so via script for hundreds of users)

So the uid is clearly rms. And as long as I do not change anything, the webadmin writes rms for the UID under system tab. But the Mailbox gets created as "Richard Stallman" and won't be found on login to roundcube via "rms" (which by itself works). But if I change something via kolab-webadmin, e.g. the language from en_US to de_DE, then the ldap entry gets completely reworked. It becomes:
dn: uid=stallmann,ou=People,dc=example,dc=com
sn: Stallman
cn: Richard Stallman
givenName: Richard
mail: richard.stallman at example.com
uid: stallman

So dn, uid and mail gets completely rewritten. And also some or all mail aliases get lost.

It's because all the uid gets generated by givenName and sn. Is this a bug or a feature?

And what happens if someone gets married and his sn changes? Will he or she lose all mails and mail aliases? And what happens if the resulting (generated) uid conflicts with some other ldap user?

What's the best way to import old kolab 2 data? I've found some script (by Jeroen van Meeuwen, btw. there are many dead links to it) which should convert the database, but it does nearly the same like me so I think it's neither a good idea to use. The Documentation is still empty regarding ldap transformation. :-(

Regards
Michael