119143 - MAB Attribute mapped to multiple LDAP Attributes may result in wrong data

Status: VERIFIED DUPLICATE of bug 126749

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Description

[John Marmion]

This bug was spun from the discussion of bug #118454. Currently the LDAP Address
Book data displayed in the Address Book is based on the hard-coded mapping of
nsAbLDAPProperties.cpp. This table suppports mapping a single Mozilla Address
Book (MAB) attribute against possible multiple LDAP Attribute names e.g.
'FaxNumber' maps to 'fax' and 'facsimilenumber'. These mappings are stored in a
single value Hashtable keyed on MAB attribute name. Thus the order they appear
in the table is significant. The table is created in reverse order. This bug may
manifest itself in two ways: 

1.When the advanced search for bug #83023 is landed, attempting to return all
the 'FaxNumber' begining with (bw) 123 would result in the LDAP query string
(fax,bw,123). Thus no data will be returned if 'facsimilenumber' is used.

2.If both LDAP attributes are used on the server then only the first value will
be displayed in the quick search.

Ideally we need to support user-defined mapping or at the very least in the case
of (1) above, create a query which allows for all attributes.

Comment 1

[John Marmion]

I have posted a patch for bug #126749 which addresses the problem of the
Advanced Search when more than one LDAP attribute maps to one Mozilla attribute.

The second issue of this bug is also related to bug #119199.

Comment 2

[John Marmion]

I am going to close this bug as a duplicate of bug #126749. The fix for it will
address this bug and the remaining functionality is covered by bug #119199.
My apologies for not attending to this sooner.

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

Comment 3

[Vedran Miletic]

v