401404 - Add UI for editable LDAP directories preferences

Status: RESOLVED WONTFIX

(MailNews Core :: LDAP Integration, enhancement)

Description

[Jeremy Lainé]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.8-1)
Build Identifier: 

The editable LDAP backend introduces 3 new preferences per LDAP directory. These preferences need to be exposed to the user.

Reproducible: Always

Comment 1

[Jeremy Lainé]

Attachment: Editable LDAP preferences v1

Attached is a patch that exposes the following preferences to the user, with en-US text for mail and suite:

* readonly : whether the current LDAP directory is read-only
* rdnAttributes : the LDAP attributes used to build the Relative Distinguished  Names (RDN) for new entries (cards)
* objectClasses : the LDAP object classes for entries (cards)

Comment 2

[Mark Banner (:standard8)]

Response based on a very quick look:

- I think we need to respect locking of prefs for the new entries (there should be some code in there already for some of the other attributes).
- nsIAbLDAPDirectory.idl I'm not really sure about adding the readOnly attribute as there is operations, but it does seem the best way. Probably also best to add a comment that the value is reflected in the operations attribute. 
- I think we need some reasonable defaults putting into the dialog for rdnAttributes and objectClasses, I'm assuming we don't need to localise these.

Comment 3

[Jeremy Lainé]

Some feedback for the different points you raised:

- I'm not sure I understand what you mean by "locking of prefs", could you please describe the expected behaviour?

- Concerning the readOnly attribute I'll add the comment you suggest.

- Concerning the default values for rdnAttributes and objectClasses, there are good defaults defined in nsAbLDAPDirectory, which work fine for existing entries. I had assumed they would also be used for new entries, but that doesn't seem to be the case. What's the usual way to address this issue cleanly, i.e. without duplicating the default values?

Comment 4

[Jeremy Lainé]

How can we make progress on this issue? It's been over 2 years since I submitted the code for editable LDAP entries and it's still not available in Thunderbird because the UI is missing.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> How can we make progress on this issue? It's been over 2 years since I
> submitted the code for editable LDAP entries and it's still not available in
> Thunderbird because the UI is missing.

I'm sorry that we haven't been able to make progress on it. The issue is bug 355350 - we just haven't got suitable backend interfaces for the UI to hook on to. Whilst this isn't going to make Thunderbird 3, after Thunderbird 3 one of the areas we will be focusing on is contacts and we'll be looking at the address book as a whole and providing better integration for remote data sources, this will include the necessary async backend interfaces but may also include a significant rewrite - then we will be able to put the code to good use.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to comment #5)
> (In reply to comment #4)
> > How can we make progress on this issue? It's been over 2 years since I
> > submitted the code for editable LDAP entries and it's still not available in
> > Thunderbird because the UI is missing.
> 
> I'm sorry that we haven't been able to make progress on it. The issue is bug
> 355350 - we just haven't got suitable backend interfaces for the UI to hook on
> to. Whilst this isn't going to make Thunderbird 3, after Thunderbird 3 one of
> the areas we will be focusing on is contacts and we'll be looking at the
> address book as a whole and providing better integration for remote data
> sources, this will include the necessary async backend interfaces but may also
> include a significant rewrite - then we will be able to put the code to good
> use.

I'm guessing general rewrite/big bug 355350 can't make 3.1.  Is there a smaller scope possible for 3.1?

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> I'm guessing general rewrite/big bug 355350 can't make 3.1.  Is there a smaller
> scope possible for 3.1?

Nope, I'm also recommending that this waits until we scope out the roadmap for the address book in more detail.

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 286438 [details] [diff] [review]
Editable LDAP preferences v1

Cleaning up patchlove queries, mailnews/addrbook/prefs/resources/ no longer exists; patch has obsoleted.

$ patch -p0 --dry-run < ~/Desktop/p401404.diff 
patching file mail/locales/en-US/chrome/messenger/addressbook/pref-directory-add.dtd
Hunk #2 FAILED at 64.
1 out of 2 hunks FAILED -- saving rejects to file mail/locales/en-US/chrome/messenger/addressbook/pref-directory-add.dtd.rej
can't find file to patch at input line 53
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: mailnews/addrbook/prefs/resources/content/pref-directory-add.js
|===================================================================
|RCS file: /cvsroot/mozilla/mailnews/addrbook/prefs/resources/content/pref-directory-add.js,v
|retrieving revision 1.36
|diff -u -8 -p -r1.36 pref-directory-add.js
|--- mailnews/addrbook/prefs/resources/content/pref-directory-add.js    2 Aug 2007 17:22:21 -0000       1.36
|+++ mailnews/addrbook/prefs/resources/content/pref-directory-add.js    27 Oct 2007 23:11:14 -0000
--------------------------
File to patch:

Comment 9

[:aceman]

(In reply to Jeremy Lainé from comment #3)
> Some feedback for the different points you raised:
> 
> - I'm not sure I understand what you mean by "locking of prefs", could you
> please describe the expected behaviour?

Preferences can be locked by the system administrator. In that case we disable the corresponding fields/widget in the TB UI. You can test where a preference  is locked e.g. via  Services.prefs.prefIsLocked("prefstring"). Can you update the patch with this? See some examples in the Account manager or it was said the LDAP properties dialog should have some samples already too.

> - Concerning the readOnly attribute I'll add the comment you suggest.

Can you drop the exposing of the attribute while the backend is not ready?

Comment 10

[Jeremy Lainé]

After so many years without progress I lost interest in using an LDAP with Thunderbird. Feel free to do whatever you see fit with the patch.

Comment 11

[Ping Chen [:rnons] (away)]

(In reply to Jeremy Lainé from comment #1)

Attached is a patch that exposes the following preferences to the user, with
en-US text for mail and suite:

• readonly : whether the current LDAP directory is read-only

I think we only support readonly mode right now.

• rdnAttributes : the LDAP attributes used to build the Relative Distinguished Names (RDN) for new entries (cards)

I don't know what is RDN.

• objectClasses : the LDAP object classes for entries (cards)

Can be customized in the Advanced tab > Search filter.

Closing, please file new bug if needed.