Thanks Adam for your insightful answer - I begin to understand the problem. But the more I look into it the worse it gets. I think this is just the tip of the iceberg. One aspect of the problem arises - as you pointed out - from my wish to press org data in a framework (vcard) designed for individuals. Another aspect is a strange (or buggy?) implementation of the ldap interface of evolution. Here is an example: I start with a contact that consists of a person with just a family name and enter this contact via the evo GUI into an LDAP addressbook. I close evo, open it again and look at this simple contact: Now the person nolonger has a family name but instead a given name identical to its former family name. Similar things happen when I enter a postal code in the evo GUI for the address and then close and restart evo. The information is not stored in the postal-code-attribute of the LDAP record but rather as part of the postaladdress attribute and then read into the big address field rather than the postal code field I formerly entered it. This is a mess to work with if information entered in one field of the GUI is shuffeled around just by writing to the LDAP database and reading it back again. Is there any reason not to use a schema exactly matching the evo GUI or, alternatively, sticking to a general vcard schema and adjusting the evo GUI accordingly? I guess I have to look for a completely different approach to my problem. I would have thought that this is a more or less standard use case but seem to be mistaken - too bad. Thanks again for the information and help!
_______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list
