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 241732 - LDAP Address fields not parsed properly
LDAP Address fields not parsed properly
Status: RESOLVED DUPLICATE of bug 222972
Product: evolution
Classification: Applications
Component: Contacts
pre-1.5 (obsolete)
Other All
: Normal major
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2003-04-22 19:40 UTC by Greg Macek
Modified: 2005-08-23 05:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Greg Macek 2003-04-22 19:40:24 UTC
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem: fields defined in an OpenLDAP server for address
(according to RFC 2252, street or streetAddress, also homePostalAddress)
should be all in one field, separated by '$' or '\'. However, Evolution
does not parse this data at all and it all comes into the address field. 


Steps to reproduce the problem:
1. Connect to LDAP server
2. View record with address information stored properly
3. 

Actual Results:

Address, city,state,zip all comes in as one line and delimiter is viewable
as well

Expected Results:

Address should be parsed out and placed into equivalent evolution address
fields.

How often does this happen? 

Every time.

Additional Information:

Problem can be found in all stable versions of Evolution at time of this
writing (1.0.x series, 1.2.x series). Have not had time to test the 1.3.x
betas.
Comment 1 Sushma Rai 2005-08-06 07:52:42 UTC
Evolution does parse the data and inserts a new line
where ever it finds the delimiter.
Even when that contact is celeted, fileds are shown
properly in the summary view.
but everyhting is displayed in address field, in the 
"Mailing Addresses" tab.

since we just get a string, we will not be able to decide
on the fileds like city, state, country, PO code, zip code 
etc.

I don't think we can fix this.
Comment 2 Sushma Rai 2005-08-23 05:58:55 UTC
Sorry, we can look at using specific ldap attributes.
Comment 3 Sushma Rai 2005-08-23 05:59:37 UTC

*** This bug has been marked as a duplicate of 222972 ***