GNOME.org
 

Re: [Evolution] names change using LDAP

On Tue, 2009-10-13 at 18:47 +0200, Lars Schade wrote:

On Sun, 2009-10-11 at 23:52 -0430, Patrick O'Callaghan wrote:

On Sun, 2009-10-11 at 20:46 +0200, Lars Schade wrote:

To illustrate the issue I start with a local addressbook and add a new
contact using the evolution GUI say for the Berlin Office of a company
called "The Big Wheel", and I fill in the name dialog as given name
"Berlin Office" and as family name "The Big Wheel". It is displayed as
"The Big Wheel, Berlin Office" exactly what I want. I can use the this
information to automatically generate address labels with openoffice,
everything perfect.

I'm not very knowledgable about LDAP, but it looks to me like you're
using it incorrectly. Using the Name subfields (First, Middle, Last,
Suffix) to stand for Office/Company is bound to lead to trouble, if not
within Evo then elsewhere you might want to use LDAP records. The field
names are there for a reason and some apps attach semantic meaning to
them. For example a Name with a space in it can legitimately be
interpreted as two names, where the second one can be represented by an
initial. This makes perfect sense for given names and makes no sense for
the name of a company.
You should reconsider how you're using LDAP. The key thing to remember
is that a "contact" is meant to represent a person, not a company.

All this is true - as a user you are over a barrel however.  I spend a
ot of time working with vCard data - to be blunt: the vCard (RFC2426)
spec is lame.  But it is everywhere and what we [sadly] have to live
with.  A vCard represents a *PERSON*,  there isn't any good [or
standard] way to represent an Enterprise (company, organization, ....).
The "FN" is the name of the vCard and corresponds to the "CN" (common
name) attribute in LDAP.  That is OK.  *BUT* the spec also *requires*
"N" which is a composite value of "Family Name, Given Name, Additional
Names, Honorific Prefixes, and Honorific Suffixes"  Of course that makes
no sense for a vCard that isn't a contact - but the client *must* shove
something in at least on of those fields.  This isn't Evolution's fault
- the spec is retarded.  [The required attributes for a vCard are: FN,
N, and VERSION.  Many implementations have a tacit requirement for UID
as well].  Evolution's internal data model is [reasonably] based on the
vCard spec as is that of Thunderous Crap, KDE's PIM (is it still called
Kontact?) , as well as most other PIMs.  Outlook has the same problem.
You need to use a "real" groupware client to avoid this lameness.

Thanks for the answers, I was afraid the problem was a bit more basic.
On the practical side: Is there a workaround you know of? 


No.


Or how do you handle contacts that are not real persons?


Badly, or not at all.  I use WebDAV to provide access to address books,
not LDAP, but I just disable access to the Enterprise folder and only
allow PIMs to see Contacts.

<aside>
I think I can make a reasonable philosophical argument that this is
correct anyway - in reality people communicate with people, not with
conglomerations.  So there should be a Contact object in the groupware
system for whoever you actually talk to rather than using an Enterprise
object as a stand in for many people [doing so violates every principle
of good customer relationship management - Hug your customer! :)]  But
in reality, especially in situations like AP & AR departments this
doesn't really work.   I've not found any good way to make any PIM
behave in a manner compatible with an AP/AR department mindset.
</aside>


On the theoretical side: The problem really only arises, once I switch from
a local addressbook to LDAP. 


Sort of;  you just don't notice it with a local addressbook.  The fields
are still being abused semantically;  for large long-lived databases
(relational or not) that is a problem.


There is a basic mismatch between the
data model in Evolution and the way data is stored in LDAP.


Not as much as you might think.  There is actually a pretty good
correspondence between vCard and LDAP in how attributes are handled.
Your problem is that the evolution schema is based on vCard which is
meant to represent a Contact;  it stuffs the attributes accordingly.


But the
problem could be solved by adapting the evolution schema for LDAP in
such a way that the different name parts are stored separately rather than
being reconstructed from the CN entry in the LDAP database. Or is there
any reason not to use separate attributes for all the vCard name
components?


No, there is no technical reason to do it in one attribute.  But LDAP
support in most clients, including Evolution, is pretty hackish
(speaking as an LDAP guy who is an LDAP admin).  The schema is not
configurable, and no client I've met [other than Turba, if you consider
a web app a client] has real schema configurability.  Ideally it would
be configurable per-address-book - but that is probably a lot of work
[for a developer].  Also I have no idea if the LDAP code supports
multi-valued RDNs which would be the best way to automatically construct
the DN for an LDAP address book.

Our solution has been: don't use LDAP for addressbooks.  We did for
years.  It seems like an ideal solution but in fact doesn't work that
well:  
(a) Evo is the only client I know of with LDAP write support 
(b) there is no standard schema, so different clients can't agree 
(c) Many clients [Thunderous Burp for example] have ***horrible*** LDAP
support.  Thunderous Burp uses a schema that must have been designed by
a crack head;  but then TB's (what an appropriate name) entire address
book is just so crappy I don't know how anyone can tolerate it.

The better solution is to use a groupware server for shared address
books and contacts, etc... and leave LDAP for sharing accounts and
aliases - which it does well and probably already contains for other
reasons.

But even that won't get you around the inherent RFC2426 limitations.

The hCard spec contains a clause that states if the ORG and FN values
are the same than the card represents an organization and not a contact.
That isn't a terrible standard to stick too,   but it doesn't help with
what to stick in "N".  OpenGroupware gets around this by just stuffing
"N" with a proprietary identification string (like "OGo1234567").   I'm
not sure if that is "correct" or not, but it works OK.  

In the Evo LDAP support is the "ORG" attribute of the address book
mapped to an LDAP attribute? ("o" I'd assume?)  Off hand I don't recall.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]