When we get writeable ldap-directories, I think we will need a way for the user to specify the directory is read-only. The reason being is that there is currently no auto-discovery route for if a user is allowed to do anything or not. I can see certain places where a user would set up a directory, then later on edit a card only to get a dialog saying they can't do that and get upset. Hopefully when they set the directory up they know if they have write access or not. So I think on the LDAP server properties dialog we should have an checkbox with the title something like "This directory is read-only to me". When the option is set we would then do all the normal activities to make the directory read-only. Of course if the user says they have write access and they don't then that's up to them, but I think this way would at least help with those who know.

From a user's perspective, I think that my having to say "This is read-only" is a terrible design decision - "I the user" may have no idea if a directory is writable or not. Additionally, the write-ability of the directory may change over time - it might be read-only now (due to configuration error) and become writable, or it might be writable now but later become read-only. A better approach would be to try to create a dummy record in the directory before opening the dialog box, and use that to probe whether the directory is writable or not at that time.

I'm only voting for this bug because it is showing as blocking 86405 (Make LDAP addressbooks editable) https://bugzilla.mozilla.org/show_bug.cgi?id=86405 To my mind this is a useless bug. It would be better to devise a way to fail gracefully when attempting to write to an LDAP addressbook without write privilges. This, one would assume, would be covered by the code allowing editing of LDAP-based address books. Hence the uselessness of this bug. And while I'm at it, it's not just useless, it's harmful, as it is a block to deployment of the truly needed function.

(In reply to comment #2) > To my mind this is a useless bug. It would be better to devise a way to fail > gracefully when attempting to write to an LDAP addressbook without write > privilges. This, one would assume, would be covered by the code allowing > editing of LDAP-based address books. Hence the uselessness of this bug. Actually I think we should do both - we should allow the user to specify it as read-only so that fields are disabled and it behaves as a read-only address book so they don't try to modify it accidentally (e.g. misplaced drag/drop, collect cards to it, try and edit card which is read only). However, we should also fail gracefully where the user doesn't specify read-only. So to some people it will be worth having and given the time to implement should be a lot less than actually doing the editable implementation its not useless or a waste of time.

(In reply to comment #1) > A better approach would be to try to create a dummy record in the directory > before opening the dialog box, and use that to probe whether the directory is > writable or not at that time. I wholeheartedly agree with this: since the LDAP administrator could make changes to a user's rights between edit events, Thunderbird should check the user's ability to add or edit each time such an attempt is made and of course pop an error dialog with details if denied. To take it a step further and address Mark's concern, we should also do the dummy record creation when the directory itself is added or modified and, if denied, ask the user if they want to mark the directory as read-only. Then don't do any further add/edit tests if that flag is set and just pop an error or whatever immediately. (Or is that what you meant, Mark?)

I think I disagree with the fundamental approach of having some test-write activity go on every time a user views a card (with potential of editing it). That would imply increased load on servers when the user possibly just wants to view further details rather than actually edit. It also has the potential of the dummy entry being seen by other applications or instances of Thunderbird and confusing them. Really I think we should take the lead from what facilities other applications provide (I think mine was from the Mail.app or Address Book.app on Mac) and look at other options later.

Hrm good point. Can we directly ask the server if the current dn has write access to the item or subtree in question? Otherwise, yes, in the interest of getting this functional ASAP, I'm fine with a "read only" checkbox in the prefs.

FYI there is an extended operation in Oracle's (Sun's) directory, as well as IBM and 389 (and possibly Apache DS), which enables you to query your own (bind DN's) access to a given DN: http://docs.oracle.com/cd/E19528-01/819-0995/bcaoi/index.html http://directory.fedoraproject.org/wiki/Get_Effective_Rights_Design http://publib.boulder.ibm.com/infocenter/zvm/v6r2/topic/com.ibm.zvm.v620.kldl0/quacl.htm http://mail-archives.apache.org/mod_mbox/directory-dev/200704.mbox/%3Ca1b4a6610704201313w114ea036v47ca2b6d9bd009bc@mail.gmail.com%3E I haven't found evidence that it's implemented for either OpenLDAP or Active Directory.