GNOME Bugzilla – Bug 739904
Can't create Contact List on an LDAP server
Last modified: 2014-11-11 11:01:57 UTC
Evolution's ldap connector when creating a new Contact List, prepares the DN as: description=newcontactlist,o=organization etc. ObjectClass used is GroupOfNames which has description as an attribute, but it's not possible to use it in the DN name as it is not an naming attribute (at least not on Novell eDirectory). Simple fix would be to just use cn attribute as a naming attribute (I created a list myself using an LDIF an I can edit a list w/o problems from the Contacts interface). Proposed patch is on: http://fpaste.org/149377 Regards.
Created attachment 290365 [details] [review] proposed eds patch for evolution-data-server; Better to attach it here. Please let me know whether it works for you, because it doesn't help much to me (a log from `LDAP_DEBUG=1 /usr/libexec/evolution-addressbook-factory -w` against OpenLDAP 2.4.35): Create Contact: vcard = BEGIN:VCARD VERSION:3.0 EMAIL;X-EVOLUTION-PARENT-UID=0;X-EVOLUTION-DEST-HTML-MAIL=FALSE:a@b.c EMAIL;X-EVOLUTION-PARENT-UID=0;X-EVOLUTION-DEST-HTML-MAIL=FALSE:b@c.d X-EVOLUTION-FILE-AS:my test list FN:my test list N:list;my;test;; X-EVOLUTION-LIST:TRUE X-EVOLUTION-LIST-SHOW-ADDRESSES:FALSE END:VCARD generated dn: cn=my.1415637766 generated full dn: cn=my.1415637766,dc=evolution-1,dc=evo Sending the following to the server as ADD Adding DN: cn=my.1415637766,dc=evolution-1,dc=evo add cn: 'my test list' add ber member: add objectClass: 'top' 'groupOfNames' e_book_backend_ldap_reconnect ... ldap_add_ext returned 0 (evolution-addressbook-factory-subprocess:28306): libebookbackend-WARNING **: create_contact_handler: 02 (Protocol error), additional info: no values for attribute type
(In reply to comment #1) > (evolution-addressbook-factory-subprocess:28306): libebookbackend-WARNING **: > create_contact_handler: 02 (Protocol error), additional info: no values for > attribute type Aha, it fails only if I use contacts which are not part of the LDAP server. If the list members are part of the LDAP server then the creation succeeds. > Adding DN: cn=my.1415638090,dc=evolution-1,dc=evo > add cn: > 'my test list' > add ber member: > 'cn=user1,ou=AddressBook,dc=evolution-1,dc=evo' > 'cn=user2,ou=AddressBook,dc=evolution-1,dc=evo' > add objectClass: > 'top' > 'groupOfNames' I think the restriction makes sense, at least partly? though it would be good to be able to create contact lists with addresses not being part of the LDAP server too.
The OpenLDAP server is fine with the 'description' attribute too, as the generated > Adding DN: description=my.1415638390,dc=evolution-1,dc=evo succeeds there as well. Nonetheless, I'm fine the apply the patch, due to the 'cn' is more common than the 'description' attribute.
Hi, I have no test environment right now (to compile out of the source), but I'm sure it will work with CN as the naming attribute because it does work that way when I create the list from the plain LDIF file. In my LDAP server, CN is the only naming attr for the GroupOfNames object class. This is probably the case with other implementations so having CN as the naming attr of the DN is the right approach imo.
Hi, yes it makes sense because it's a Contact list and not the general e-mail address list. When I change the Contact associated in the list, it is picked up immediately, because the member attribute type is the DN, and not the String (this is the constraint), so you can't add any other e-mails or strings.
Thanks for the confirmation. I pushed the change for the next release: Created commit 3ca6c6b in eds master (3.13.8+) [1] Created commit 3fed107 in eds evolution-data-server-3-12 (3.12.9+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=3ca6c6b