On Tue, 2003-01-07 at 23:01, Chris Toshok wrote: > > Hm, were you trying to replace the existing objectClasses with person? > There shouldn't be a conflict between person and account that I can see.
Yes but not intentionaly. I finally resolved the problem but can't understand why evolution is unable to get the thing to work. Here are the objectClasses needed for LDAP entries corresponding to user account (to log in): top account posixAccount shadowAccount Here's what evolution need to store 'mail' attribute: top person organizationalPerson inetOrgPerson attribute sn is needed for the person objectClass I resolved the problem by modifying manualy an entry with the following ldif: dn: uid=test,ou=People,dc=test,dc=com objectClass: top objectClass: account objectClass: shadowAccount objectClass: posixAccount objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Test Why Evolution couldn't add the missing objectClass and attribute is beyond me. Actually I may have an idea: objectClass is a mutlivalued attribute. If you want to update it you have to recall all objectclasses that were already present in LDAP entries. If you do not, it's assuming you wan't to replace the objectclass attribute. In our case replacing atrribute objectClass (defined to account, posixAccount and shadowAccount) with the person stuff is not possible because of attributes that need the one you're overwriting (uid, uidNumber,...). I'm affraid evolution is not including objectClasses of the already existing entries when it tries to update an entry. I may be wrong. Just an idea. Regards -- Joaquim Fellmann <[EMAIL PROTECTED]> _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
