Bug 2721 - LDAP lookup and address formatting
Summary: LDAP lookup and address formatting
Status: NEW
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI/Compose Window (show other bugs)
Version: 3.8.1
Hardware: All All
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2012-08-12 09:45 UTC by Konrad Pióro
Modified: 2012-08-14 08:14 UTC (History)
0 users

See Also:


Attachments

Description Konrad Pióro 2012-08-12 09:45:27 UTC
When the DN is cn=John Doe,dc=something the email address in the input field gets formatted as cn <mail> (John Doe <john@doe.com>). However this is not correct for all types of LDAP layouts. In my company I use cn=SYSTEM_ID, where SYSTEM_ID is some identification number, and when I send mail this is incorrectly represented as SYSTEM_ID <mail>. It would be good to allow to change this formatting to "givenName sn <mail>" or "sn givenName <mail>".
Comment 1 Ricardo Mones 2012-08-13 08:40:46 UTC
Sorry, but you're abusing LDAP schema as cn, which stands for commonName, is not intended for system ids, but for common names (surprise!).

There's plenty of LDAP attributes in standard schemas which can be used for your purpose, like "uid", "userid", and several others. If that's not enough you could even add your own defined attributes to existing class or even new classes for your objects. There's absolutely no need to abuse existing attributes, so to me this looks like a PEBKAC with your LDAP admin.

Furthermore I don't think Claws Mail should encourage such bad practices by supporting them, so an invalid/wontfix request IMHO.
Comment 2 Konrad Pióro 2012-08-13 09:21:28 UTC
Let me clarify because I don't think you get the idea why this is needed.

We have our own Private Enterprise Number and custom schemas. The referenced ID is actually equal to UID, which is used to also construct a DN of objects.

I agree with you, that Common Name is "Name Surname" for people (eg. posixAccount), but it can also mean almost anything else for non-people, depending on the type of object. It is not good for CN to mean different things, so a compromise is needed for all DNs to be consistent across the directory.

We have a few branches in our tree called cn=ID,ou=something,dc=company, where the unit "something" denotes a particular function of the object. Each have diffrent schemas and objectClasses. It is then most efficient for our applications to browse the directory, instantly pulling correlated entries from every branch that is needed, without issuing a "tell me which DN has attribute uid X in unit Y" query for every uid specified.

Or are you telling me to change the DN to uid=UID,ou=something,dc=company? Will then Claws correctly pull givenName and sn from the object?
Comment 3 Ricardo Mones 2012-08-14 08:14:56 UTC
Thanks for the clarification, but I think you've already answered yourself, the only thing remaining is you to test your suspects.

> Or are you telling me to change the DN to uid=UID,ou=something,dc=company? Will
> then Claws correctly pull givenName and sn from the object?

Sure, these and more attributes are always retrieved because they are supposed to contain the addressbook's display name (displayName attribute, or cn if displayName is empty), the first name (givenName) and the last name (sn), no matter the DN you choose for your objects.

Thinking it again I guess the easier for you is to add a displayName attribute for your defined classes where it's missing, if any. And use it for the value you want to appear on your addresses, of course :)

Note You need to log in before you can comment on or make changes to this bug.