After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 222972 - no support for traditional LDAP address schema
no support for traditional LDAP address schema
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Contacts
pre-1.5 (obsolete)
Other All
: Normal minor
: Future
Assigned To: evolution-addressbook-maintainers
Evolution QA team
evolution[ldap]
: 241732 316460 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-04-02 23:48 UTC by Philipp
Modified: 2021-05-19 12:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philipp 2002-04-02 23:48:28 UTC
An issue with LDAP:
Evolution always stores the persons' addresses in a single attribute per
address. Apart from the problem that the format it puts the field together
is not suitable for addresses in typical german format, it's not possible
to use the traditional InetOrgPerson attribute combination

- "street"
- "localityname"
- "postalcode"
- "statename"
- "countryname"

which quite a bit software out there uses.

To be more exact, while there are incompatibilities between different 
programs, Evolution is the only program i found which uses exclusively
the "PostalAddress" attribute to store the address. This makes it somewhat
bad at interoperability.

Please feel free to contact me for more information regarding other
program's handling of the matter, or pointers to RFCs.

Bye, and keep up the very good work.
  Philipp
Comment 1 Sushma Rai 2005-08-23 05:59:38 UTC
*** Bug 241732 has been marked as a duplicate of this bug. ***
Comment 2 Sushma Rai 2005-09-19 07:52:40 UTC
*** Bug 316460 has been marked as a duplicate of this bug. ***
Comment 3 Geert Janssens 2007-08-19 13:59:46 UTC
I think this is a very difficult bug to solve.

Evolution allows for 3 different addresses:
Home address (homePostalAddress in LDAP)
Work address (postalAddress in LDAP)
Other address (otherPostalAddress in LDAP)

On top of this, inetOrgPerson in LDAP provides the extra attributes "street", "postalcode" and so on that the original poster mentioned. The problem with these attributes is that they allow for only one address to be specified in LDAP.

The fact that LDAP allows you to add multiple street instances of the street attribute to one object doesn't solve this limitation. Suppose you have entered two addresses for one contact, using street, postalcode and so on, eg:

Address 1:
street: Shallow Road 53
postalcode: 7980
localityname: Brussels

Address 2:
street: Flower Alley 76
postalcode: 2074
localityname: Grobbendonk

(Note, I am using address layouts typically for Belgium, but the story remains the same when using American style address information)

LDAP just puts all of this together like:
street: Shallow Road 53
street: Flower Alley 76
postalcode: 2074
postalcode: 7980
localityname: Brussels
localityname: Grobbendonk

I deliberatly switched the postalcodes in my example, because that is what you can expect LDAP to do as well. So once you have added two addresses to one contact, you can't tell anymore which street belongs to which postalcode and localityname.

I think that's why the xxxPostalAddress attributes were created for in the first place: to enter complete addresses in one LDAP entry.
There is another big advantage to the xxxPostalAddress attributes: most addressbooks that separate postal codes, states and cities, tend to recombine them in only one way: the American way. For Europe, this is incorrect. The xxxPostalAddress fields allow to store the address in the way it is intended to be used. This is a big plus if the default address formatting isn't correct.

All in all, I peronally believe Evolution is dealing with LDAP addresses in the most correct way (although not perfect). For example, Kontact (KDE's address book) uses the separate attributes, but Kontact always maps this to the home address, and ignores the business address. In addition, it can't save changes to the address.

On the other hand, I also think there is still room for improvement.

There are a few possible ways to address this:
* Continue to use xxxxPostalAddress, but encode the information in a way that Evolution knows which item is which. For example store the above address in homePostalAddress as
homePostalAddress: street:Shallow Road 53$postalcode:7980$localityname:Brussels

Like this, Evolution can extract each field into the correct text box of the contact form.
Disadvantages:
- another incompatibility layer is added and the format in LDAP is no longer easily used by other address books (they too will then have to interpret all the fields).
- the address formatting (European vs American) is still an issue, as Evolution itself assembles the xxxPostalAddress fields, not the user

* Introduce new attributes in LDAP, such as: homestreet, otherpostalcode and so on. This way Evolution could store three addresses as it does now with the xxxPostalAddresses.
Disadvantages:
- this will require changes to the evolutionPerson LDAP schema. Schema changes are not easily done and may cause severe compatibility problems.
- the address formatting (European vs American) is not addressed with this solution either

* Just keep on using the xxxPostalAddress attributes as they are, but instead disable the extra fields in the Contact entry form for City, Zip and so on, to force addresses to be filled in completely in the Address field. This matches the LDAP behaviour most closely. As an added advantage, the addresses can  be entered in the correct formatting for any country, because the xxxPostalAddress fields are essentially free form. Such an approach should of course be well documented in the user guide (or appropriate help section).

Personally, I think the last option will cause the least amount of issues, although it doesn't solve one side effect as mentioned in duplicate bug #316460:
The maximum field length of address entries in Symbian base phones is usually too short (I have no experience with such phones, so I don't know how big the impact is). I can imagine other solutions for this, although not immediatly an easy one.

Similarly copying an address from LDAP to a local address book in Evolution won't automatically split the fields either. For me this isn't really an issue in itself, but it may cause the same export and sync problems.
Comment 4 André Klapper 2015-01-07 17:43:50 UTC
Fixed by bug 426893?
Comment 5 André Klapper 2021-05-19 12:28:04 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new bug report ticket at
  https://gitlab.gnome.org/GNOME/evolution/-/issues/

Thank you for your understanding and your help.