Open Bug 86405 Opened 23 years ago Updated 2 years ago

Make LDAP addressbooks editable

Categories

(MailNews Core :: LDAP Integration, enhancement, P3)

Product:
MailNews Core
Component:
LDAP Integration
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: olen, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs,
URL
)

Details

(Whiteboard: [Please: No useless comments][gs]) 

For both individuals and companies i believe it would be a great advantage to be
able to add entries to an LDAP-address book, not just search it.
confirming bug; it'd be nice to be able to add entries to the LDAP server.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Adding is a nice and important feature but I would go a step further, saying
'ADD, EDIT, DELETE' would be highly appreciated by me. I only use one single
data source for authentication and as address book - my LDAP directory.
Currently I always have to use an LdapBrowser to maintain it.
Target Milestone: mozilla1.0 → mozilla1.2
I would like to be able to have this with Rolodap, http://rolodap.sourceforge.net .

It would be very, very slick!
I'd love this feature for use at work and home. Several _nice_ possibilities
come to mind.

Number 1: Tunnel LDAP over SSH to work so I can share my address book between
all mail clients and between work and home. I already use IMAP and tunnel that
for a single shared mailbox so that'd be amazing.

Number 2: Using LDAP for a consistant, server-based address book solution for
work that allows easy back-ups and easy mail-client changes (to other clients
with decent LDAP support at least).

I'd really love to see this stuff land.
*** Bug 149990 has been marked as a duplicate of this bug. ***
I've been using LDAP for a few weeks now for our entire company and I think
allowing people to write to their LDAP directory would minimize administrative
work for the directory. 
For now I have to add any changes manually to the directory, but people over
here would like to be able to add addresses themselfs without using some other
tool than the Mozilla Adressbook.
QA Contact: yulian → gchan
any comment from the moduleowner to this enhancement request? a target
milestone? an argument for not implementing it?

Module: Mail/News
Owner: Scott MacGregor
Peers: Seth Spitzer, Scott Putterman, David Bienvenu
Who can do This and How can we do this?
Is something we need missind somewhere?

Or We just need to add a Write LDAP function on the Address book and Things will
be done.
I think all of the major functionality has already been written; just need to add a function to export the address book as LDIF to an LDAP db rather than a file.
Are you sure? I don't think it is that easy...
I don't see any LDAP defination there... from my point of view it will be much
complicate.
Addition of read-write as well as the current LDAP search capability is a great
idea.
As well as allowing for shared address books that can actualy be viewed, the
ability to edit and add new entries to the tree coupled with shared calendaring
via DAV would fill the missing chapter from the 'Exchange replacment HOWTO'

Would also be a good way to GUI admin LDAP auth'd accounts, aka Directory
administrator 
http://diradmin.open-it.org/index.php
Blocks: majorbugs
Target Milestone: mozilla1.2alpha → ---
Depends on: 116692
I've been thinking a bit about what a really good (writeable) LDAP addressbook
would be like and have written down some ideas:

http://nakedape.cc/wiki/index.cgi/WritableLdapAddressBookIdeas
*** Bug 168365 has been marked as a duplicate of this bug. ***
And use DSML-formated XML (http://www.oasis-open.org/) to import/modify entries
*** Bug 225205 has been marked as a duplicate of this bug. ***
Maybee it would be a good idea to implement a connection to Kolab, 
which would allow to keep mozilla free of all internal details of the 
ldap server, examples for the neccesary code should be found in the kroupware
additions to kmail, so it should be a hopefully relatively simple task
*** Bug 203741 has been marked as a duplicate of this bug. ***
@Helmut #16
Mozilla uses its own LDAP-Framework. And one of the mainfeatures of LDAP is the
generalization (no dependency to any server!)

@all (especially developers)
I want to implement this. I need more information about how (and where) to do
this. What needs to be done, etc.... Maybe someone can help me.
*** Bug 232696 has been marked as a duplicate of this bug. ***
Depends on: 124897
Is somebody working on this bug?

I recommend keyword "nsenterprise".

For all who wants to get involved:

There is a "The LDAP C SDK Programmer's Guide documents the Mozilla LDAP C SDK,
a software development kit (SDK) for writing Lightweight Directory Access
Protocol (LDAP) client applications." available. "This guide is intended for use
by C and C++ programmers who want to enable new or existing client applications
to connect to LDAP servers."
http://www.mozilla.org/directory/csdk-docs/preface.htm

The document also contains a linklist to many external sources.

Another document is available at
http://www.mozilla.org/directory/

Maybe someone should have a look at the libraries at
http://www.openldap.org/

I am very interested to see this bug solved.

Markus

PS: Let's do some more promotion to get votes for this bug!
Hi,

if anyone is implementing this, this should be conformant with the
LDAP scheme defined in Bug 116692

Furthermore, it would be nice if the mozilla addressbook supported
address categories and multiple (not just home/work) addresses in 
LDAP (see bug 228715). Maybe this should be resolved before LDAP
write access.

regards
Hadmut


IMHO it is more important to implement the writeaccess as fast as possible and
do some corrections for implementing some obscure feeatures (more than one
address per entry) and so forth!
This is (IMHO) the most missing feature in Mozilla!
Flags: blocking1.7+
OK, 
but then it should correctly read and write the defined 
Mozilla LDAP schema. 

What about ambiguities? As can be seen from 
nsAbLDAPProperties.cpp many Addressbook property types
do have more than one LDAP equivalents
(e.g. LastName = sn or surname, CellularNumber = 
mobile or cellphone or carphone)


Should mozilla allow to freely configure the LDAP 
attribute name for each property (per LDAP directory)?

regards
Hadmut

A mapping from Mozilla-Addressbook entries to specified entities in a
LDAP-Schema would be definitly nice. Like the mapping you have when
synchronising a Palm to an Outlook-Source.
For fast results implementing the Mozilla-LDAP-Addressbook-Schema (as proposed)
would be a way to go, because so you can have a working addressbook without too
much to configure.
Please take your discussion elsewhere and don't set silly flags. There's no
patch, bug 124897 needs to be resolved first and there's no way that's going to
happen in 1.7. Besides, you're not even allowed to set blocking to +, drivers
decides on that.
Unless you're actively working on resolving this bug there's really no reason to
comment.
Flags: blocking1.7+
Then do something about it and don't make useless comments too! This is one of
the most annoying bugs in mozilla!

> Please take your discussion elsewhere and don't set silly flags. There's no
> patch, bug 124897 needs to be resolved first and there's no way that's going to

THEN RESOLVE IT! But you mozilla people like discussing more about reinventing
the wheel!

> happen in 1.7. Besides, you're not even allowed to set blocking to +, drivers
> decides on that.

Then the decision is a wrong one!

> Unless you're actively working on resolving this bug there's really no reason to
> comment.

I can give you more than 1000 examples where noone is working and only
discussing. No reason to flame!

This is too working on the bug. I don't have the time to dig into the
mozilla-code and do it myself but mabye this are some suggestions for the
person, who is implementing these!

Thanks, now I feel even less compelled to work on this bug. I've worked on bug
124897 specifically so this bug could be fixed some day. Discussions that turn
bug reports into useless lists of vaguely related RFEs and ranting just make
working on Mozilla more painful.
Hello, 
 
this would be *really* a *very* important feature. Many companies need it! 
Are there any fixed plans for this feature?
Summary: Possibility to add entries to an LDAP-address book → Make LDAP addressbooks editable
(In reply to comment #21)

> if anyone is implementing this, this should be conformant with the
> LDAP scheme defined in Bug 116692

Bug 116692 seems to be on a very good way to be checked in.

> Furthermore, it would be nice if the mozilla addressbook supported
> address categories and multiple (not just home/work) addresses in 
> LDAP (see bug 228715). Maybe this should be resolved before LDAP
> write access.

Yes, that would be nice, but I disagree with the priority.

Please, let there be write support in the near future (top on Mozilla X-mas
wishlist). I am really hard willing to test it with OpenLDAP and OpenExchange
and then to roll it out.

Markus
Blocks: 254504
Hi everybody,
I saw that more than 100 people voted for this bug. Maybe you can also vote for
Bug 116692. It is basically a pre-requisite for most other LDAP bugs. It would
make live for Mozilla LDAP developers as well as users much easier if we could
rely on an official basic LDAP schema for Mozilla.
Product: MailNews → Core
*** Bug 254504 has been marked as a duplicate of this bug. ***
No longer blocks: 254504
I'm just wondering, is it possible to do this as a mozilla-
extension?
This Is needed to allow companys to move from Exchange server.

The creator of our mail server are adding this to the server side in this 
release of beta's but are struggling to find client's to plug into this.

This in my opinion is the only way forward for group address lists.
Isn't bug #275476 a dup of this bug?
No longer blocks: majorbugs
*** Bug 275476 has been marked as a duplicate of this bug. ***
(In reply to comment #29)
> Please, let there be write support in the near future (top on Mozilla X-mas
> wishlist). I am really hard willing to test it with OpenLDAP and OpenExchange
> and then to roll it out.
Thus, it would be great to choose the schema ; to keep the ability to maintain a
common LDAP access between Mail.app, Thunderbird, Evolution, and Exchange.

And it would be useful to be able to add new fields/attributes to the address
record. E.g. in Germany many people get additional phone numbers from their 
VoIP-Providers. Since you need to store both, the normal and the VoIP number,
and you need to distinguish (because of different costs for calls) between them,
would be nice to be able to add random new entry types.

Another vote on this issue .. I'm using Thunderbird across a largeish private
network, for my family and extended family across two countries.  Everyone in my
family uses a private LDAP service I host on my linux box, and use it as a
communial address book, holding addresses, birthdays, and heaps more.  It's
become one of the killer apps within our family, which is a huge thing as many
of them are NOT "technology people".  Having this option would just help SO
much, and I think its features like this that really put Thunderbird above and
beyond the other apps out there.  Please, consider adding this in.
(In reply to comment #38)
> Another vote on this issue ... Please, consider adding this in.

Comments like this only serve to waste developers time (through having to read 
bugmail etc). Please read the Bugzilla Etiquette 
(https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) before commenting on 
any more bugs.

And anyway, we are already considering this (see 
http://wiki.mozilla.org/MailNews:Home_Page) and have been for a while. With the 
recent ldap changes we are now in a better position to push ahead with this.
Whiteboard: Please: No useless comments
As more home Linux users start using LDAP to sync between several computers on
their home networks, being able to ADD/EDIT LDAP entries becomes more important. 
*** Bug 313003 has been marked as a duplicate of this bug. ***
Well, it doesn't look like a lot is happening either here nor on the Wiki page. So I think adding this comment is more a helpful reminder than a waste of developers' time: I really think you should push ahead with this. Thanks.
Hi,

there is another issue with latest Thunderbird 1.5:

It still does not support Kerberos for LDAP authentication. As far as I learned from other comments and bug reports, this is owned to the fact, that the LDAP code in Mozilla/Thunderbird seems to be stone-age-old and difficult to handle.

This is another argument for removing LDAP from Thunderbird and instead creating common plugins.

regards
Hadmut

I've been looking for this one for YEARS now -- and seem to recall a Mozilla developer explaining why this was a difficult feature.  Can someone remind me why this [might] be the case?  I like to try and understand these things, and perhaps contribute[in a very small way] to a solution.
*** Bug 340337 has been marked as a duplicate of this bug. ***
(In reply to comment #27)
> bug reports into useless lists of vaguely related RFEs and ranting just make
> working on Mozilla more painful.

That makes no sense at all -- new developers frequently implement a bug fix for an OSS system only to find out its not really how it should have been done or what was really wanted.  These discussions are very helpful for deciding how development should procede.

Thanks for making an initial patch, but in all honesty it may be someone else's that makes this happen for real.  Lets figure out the best way to do it and make it work.
(In reply to comment #39)
> (In reply to comment #38)
> > Another vote on this issue ... Please, consider adding this in.
> 

+1

> Comments like this only serve to waste developers time (through having to read 
> bugmail etc).

Yes and not.
I'm a OpenSource developer too, and if there is a lot of person that vote for a bug resolving, I can't hide my self to try to solve it...
I don't know what problem type is to add this feature, but if you need some money contribution for "help" to solve it, I ( and all the community, I think) can help to do it. If you say "Yes, this can help for found some time/developer that has time to do it", I'll very happy to organize a campaign for collect some money! (Like k3b does and it was a complete success: he ask for 1k Euro and receive 4k!)

Hope that this not annoying you and the reader,
Michele Petrazzo
Depends on: 355347
Depends on: 355350
Depends on: 355363
Depends on: 356208
I know this has nothing to do with this bug, but I'll add it anyway.
I think it would be much better if Thunderbrird could read/write/delete address book from a (My)SQL server. 
In my oppinion LDAP is to complex a "database" for just phonebook.



> I know this has nothing to do with this bug, but I'll add it anyway.
> I think it would be much better if Thunderbrird could read/write/delete address
> book from a (My)SQL server. 
> In my oppinion LDAP is to complex a "database" for just phonebook.

Just in case you don't know: LDAP is THE (one and only) standard for User directories and phone book. Everyhing else is propriatary.

It also has the advantage of being easy to configure for a robust network including replication, having an inherent logical structure, having multiple interoperating implementations, and being extremely efficient in environments where reads vastly outweigh writes in frequency.

However, this really isn't the place for this conversion so I think this'll be my first and last comment on the matter.
Depends on: 358333
Depends on: 360777
Depends on: 135231
*** Bug 361431 has been marked as a duplicate of this bug. ***
Are there tech issues which haven't been discussed here? I wonder if there is something blocking implementation of what seems a critical feature for many, and whether there is anything non-coders can do to help.

A default mapping in prefs.js between moz attribute name and LDAP DN would perhaps be adequate for an initial implementation, and would at least allow sharing between moz clients, surely a huge step forward.

The refs in Comment #20 and especially http://www.mozilla.org/directory/csdk-docs/addmod.htm seem to have the relevant API info; are more suggestions required as to how this might be implemented?

Our users have LDAP personal addressbooks.  We currently use Evolution but would like to offer them Thunderbird as an alternative.  Unfortunately the inability to edit their LDAP addressbooks makes using Thunderbird impractical for us at the moment.  Regarding starting development of the feature, I may be able to get our management to offer a financial bounty if that would be helpful.  Regarding LDAP schemas, as we already use the Evolution LDAP schema it would be useful if Thunderbird could use that schema also so either client can read/write addresses successfully.  Thanks, Murray

Hello, i tried to use evolution mail, you can edit contacts there, but evolution is very bugged and slow, thunderbird is very much better and i hope that some day this function will work, til there we can only wait.
I too have been waiting years for this (first with mozilla suite).  The lack of this ability is one of the two reasons I (occasionally) lose the case against exchange server/outlook in my smaller clients.  It's not a frequent occurrence, but losing to MS because of a technically superior solution is painful.  Which is what has prompted me to this action.

Organizations of all sizes _need_ shared address books. The alternatives for TBird are, to put it politely, clumsy.
(http://kb.mozillazine.org/Sharing_address_books)
I work entirely with smaller organizations (<100 people). There are many ways in a small organization for the process of relying on a single administrator updating the LDAP-based address book to break down.  So break it does.  

Noting the age of this bug, I despair that TBird is becoming another mozilla suite w.r.t. essential features getting lost in the cloud of bugs (in reference, just check out the history of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=47838)
especially after reading comment #39.

Perhaps there is another way.

It's not like this is an insurmountable problem -- witness Evolution.  Or take a look at what Alexander Hartner has been doing for years for the Mac's AddressBook application.
http://www.j2anywhere.com/j2anywhere/projects/ab2ldap/index.jsp
http://www.j2anywhere.com/j2anywhere/projects/ab4ldap/index.jsp
http://www.j2anywhere.com/j2anywhere/projects/abxldap/index.jsp
I can attest that it works, and very well at that.  But only on Mac, and only with Mac's AddressBook application.

A couple of years ago (2005-03-01, according to my email archives) I tried to persuade him that there would be a market for his tool in the mozilla world.  Perhaps a few others on this list could contact him and ask him if he'd be still be willing to make the attempt.

I'd certainly be willing to pick up the thread.  I still have the $150 (CDN) that I was willing (and never got the opportunity) to contribute to the fixing of bug 47838.  I also have a client willing to stump up another $300 (CDN) if their users can edit their shared LDAP-directory address book from TBird.  If just a few of us were to contact him, I think we would very quickly have a very useful tool.  And the overworked developers would have yet another working model to see in action, with features that are good, bad, and missing. 

It wouldn't actually fix the bug, but it would "route around it".  That would be better than having people getting locked into Outlook and Exchange because they can't update an LDAP-based address book using the TBird interface.
We've given up waiting!
From post 116692

I've had quite a few people email me regarding this solution so here's the
details.
Here's a few links for you to look at hope they help everyone:-

We use (on this site):- Vpop3(mail server) www.pscs.co.uk they have Vcap
(online calendars) and use LDAP (with an link to the Vpop3 server for outlook
contacts (Beta version)) But we only use the Vpop3 email server bit at the
moment. Their support is V good and the product is in continuous development.

We are using (on this site):-Xcconect for the calendars and contacts
http://xcnetwork.com/index.jsp this is vgood but expensive. Support is good
(what we've needed of it) IIE needs a bit of a tweak on the server, but other
wise no problems.

It has been suggested that we looked at:-

Kolab 

http://www.kolab.org/ with the Thunderbird plugin
http://www.gargan.org/extensions/synckolab.html

Not looked at yet

and 

Visnetic

Again not looked at yet

The problem we have is that we are multiplatform and multi sites, with PC's
only(this site), Pc/Mac and Mac only sites with various per site server solutions (an IT
nightmare!). I try where posible to use multi-platform software.
Is it possible to implement a remote addressbook as an extension? 

If that is possible, to have an extension that does the same as what we want to use LDAP for, but with a different communication protocol. I guess there would be fairly many who could write a js/python extension as opposed to hacking C++ LDAP code.

regards,
Tarjei
I'm working in a SME and we have standardised on Thunderbird as our email client.  All office bound employees have IMAP accounts (cyrus).  It would be a huge plus if we could have shared access to an editable address book for the whole company.  I have already set up read-only access to an LDAP address book (the default behaviour of not showing entries until you start to search is very counter intuitive too) that can be edited with LDAP editing tools, but these are too "unfriendly" for the average user.  Edit support in Thunderbird would put another nail in the coffin for those users who complain about not having Outlook.  This feature (plus an easy shared calendar) would position Thunderbird as a real Outlook / Exchange killer.
It's utterly mystifying that this hasn't been implemented yet. Thunderbird is such a great rock solid IMAP client and is more or less there now on the Calendaring side with Lightning extension. 

So the missing part of the puzzle for all the tens of thousands of SMEs out there, like the four media companies I support is shared address books. We've all got LDAP servers kicking around in one form or another. Come on let's have this feature and get using them!
If you guys are so eager to have this feature, then why don't you hire a programmer to implement it?  It's obvious that none of the regular Mozilla developers are interest enough in this feature to volunteer their time to write the code, so you big money SME guys will just need to pony up the cash to pay someone else.
(In reply to comment #60)
> If you guys are so eager to have this feature, then why don't you hire a
> programmer to implement it?  It's obvious that none of the regular Mozilla
> developers are interest enough in this feature to volunteer their time to write
> the code, so you big money SME guys will just need to pony up the cash to pay
> someone else.

Precisely because most SME's are not big money. They are also not generally in the business of commissioning custom software. They wouldn't have the faintest clue how to go about it.

I think what myself and other similar voices here find so perplexing is why someone interested in furthering Thunderbird wouldn't code it. It seems like such an obvious thing from an end user point of view.

I'm deeply grateful to the developers for building Thunderbird. I'm a long time user. What I'm trying to do here is attract attention to something that from my point of view is of huge value to Thunderbird as a project.  Others seem to agree.

I know little about the internal structure of Mozilla, I'm sure this is not the right forum for this discussion but time and time again Googling for 'shared addressbook' has brought me to this page and no little frustration - this time I decided to act.

If there is a place where people with the talent for making this happen hang out then please direct me to it. I'll see if I can rustle up a bounty.
Hm... may be the future edition of Bugzilla instead of voting can provide link to some account where people can drop coins. I think there are such services. I think people do open source because they like to do it, not because somebody needs it... so if they do not like to do it because they like it, there should be way to motivate them to do it because this way they can meet their other needs. And people like Greg can ask all SMEs to drop coins until the feature happens.
If you are not a developer but are interested in supporting this feature financially, you could start a pledge at http://www.pledgebank.com/ and then post a link here so the multitude watching this bug have the opportunity to pledge.

An example of a successful FOSS development pledge: 
   http://www.pledgebank.com/nouveaudriver

Then, use the money to hire a competent Mozilla developer to implement this.  I don't know how much it would cost to implement this, but I think $10000 would go a long ways.  You may want to contact potential developers in advance and get a rough estimate, as this will give your pledge more credibility (that the proposed development will actually take place once the money has been raised).
Greg: In terms of finding people/companies with the talent to implement this, I would start here: http://consultants.mozdev.org/consult/index.html

I would like to remind people of the bugzilla etiquette https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - half the comments here don't meet this.

Having said that, I'd like to point out that most of the restructuring in the address book recently has been largely aimed at making it easier to implement writeable ldap.

There is still some important restructuring to do and new code to write, most of which is covered by the bugs that this one depends on. 

I had been aiming to work on this over the last few months, however SeaMonkey needed my help more. The address book is now almost in a position where I can start work on helping this progress. So hopefully sometime in the next month or so I might get some patches started.

However, please don't bug me (either direct or on this bug) unless you're actually going to help me - my time is my own.
A few months ago I mentioned I had a patch in progress for this bug. I was then contacted by Jeremy who has been working with me on improving it and moving it forward.

We have progressed the patch to a stage where the backend for writeable LDAP address books will largely be in place once it is reviewed and checked in.

However, there is still some significant work involved in getting the UI hooks updated and in place for writeable LDAP address books as they need to be capable of asynchronous editing rather than synchronous as is the current case for the address book dialogs.

As the UI is virtually unusable for writeable LDAP address books (e.g. success/failures as currently printf statement outputs), we won't currently be enabling it in nightly builds - what is there is likely to be considered as capable of causing dataloss and hence its not right that we enable it to general testers until we have some confidence in it, with a half decent UI. Once we have a half decent UI in place, then we'll probably allow it to be enabled via a preference.

The patch is now attached to bug 356208 (attachment 281949 [details] [diff] [review]).

Once we get that reviewed and checked in, it should be easier for us to develop and test, so hopefully, the UI will progress a bit quicker.

I'd like to say thanks to Jeremy for all the hard work so far.

As before, this is a status update, please don't bug either of us (or comment here) unless you're going to help. We're both doing this in our own time, and we'll progress it as and when we get time.
Depends on: 401404
Flags: wanted-thunderbird3?
Assignee: srilatha → nobody
Flags: wanted-thunderbird3? → wanted-thunderbird3-
QA Contact: grylchan → ldap-integration
Product: Core → MailNews Core
Hi,

Not sure it this will be helpful, but we have done quite a lot of work implementing LDAP for both authentication and addresses and we came to the conclusion that you can never satisfy everybody, so there is no point in having your own schema. We use the following openldap and samba schemas: core.schema, cosine.schema, nis.schema, inetorgperson.schema, samba.schema and I believe that inetorgperson, along with it's parents, has enough to do a decent address book. In our office we can access the address book from our fax machine, our VoIP phones, Thunderbird, Outlook and Squirrelmail.

I think this is a case of KISS. The only issue we had to decide on was a unique value within the addressbook, which we decided on a mixture of the person's first and last name and company. An ID number of some sort would have been better but as far as I am aware there is no LDAP equivalent of an auto-increment value. I think the first major project that decides a "proper" addressbook indexing structure that uses the main default schemas will drive the development.

We ended up writing a very simple PHP frontend because there were so many incompatible schemas out there.
(In reply to comment #67)
> Not sure it this will be helpful, but we have done quite a lot of work
> implementing LDAP for both authentication and addresses and we came to the
> conclusion that you can never satisfy everybody, so there is no point in having
> your own schema...

This isn't anything to do with this bug. Thunderbird has a default schema which it fits best with, but is also flexible, see https://wiki.mozilla.org/MailNews:LDAP_Address_Books. The current state of the schema capabilities does not block this bug.

Comment 66 is still basically right. We need extra work on the UI to allow editing in asynchronous situations, whilst some work has been done towards that, it still needs consideration in more detail.
(In reply to comment #68)
> Comment 66 is still basically right. We need extra work on the UI to allow
> editing in asynchronous situations, whilst some work has been done towards
> that, it still needs consideration in more detail.

Is there a particular bug that is covering this synchronous -> asynchronous change?  Or do you know who is heading up this effort?
I'm not aware of a bug for it specifically yet, but I suspect there will be one.  Mark is probably driving this to some degree, though he's also trying to multiplex with a bunch of other stuff.  We're going to have some discussions about this next week, so hopefully there will be more progress to report then...
(In reply to comment #63)
> If you are not a developer but are interested in supporting this feature
> financially, you could start a pledge at http://www.pledgebank.com/ and then
> post a link here so the multitude watching this bug have the opportunity to
> pledge.

Right. Enough. Let's put our money where our mouths are. I have started a pledge on Pledge Bank. My company will pay £100 towards getting this solved, and if the 51 other people on the CC list do the same we will have over £5000 to contribute to resolving this.

It is now live at http://www.pledgebank.com/LDAP-AddressBook

S**t or get off the pot, folks.
(In reply to comment #71)
> (In reply to comment #63)
> > If you are not a developer but are interested in supporting this feature
> > financially, you could start a pledge at http://www.pledgebank.com/ and then
> > post a link here so the multitude watching this bug have the opportunity to
> > pledge.
> 
> Right. Enough. Let's put our money where our mouths are. I have started a
> pledge on Pledge Bank. My company will pay £100 towards getting this solved,
> and if the 51 other people on the CC list do the same we will have over £5000
> to contribute to resolving this.
> 
> It is now live at http://www.pledgebank.com/LDAP-AddressBook
> 
> S**t or get off the pot, folks.

I pledged, I am also working on other initiative to get an developer working on this, in the Netherlands. I am thinking of setting a reward, or bonus or hiring a developer.

I would really want this to be implementation right, with standard supported ldap schemas, so no custom mozila schema, i need other clients like gnome evolution to be able to access and change all the ldap data to.

Best regards,

Jelle
Do records of pledging GBP100 count as "useless comments"?  

Regardless, I'm in. Can't do anything about rounding up a developer, but I'm good for the money.  Hope this works better than my last attempt to do something like this (https://bugzilla.mozilla.org/show_bug.cgi?id=135636).  At least there's pledgebank now.
My useless comment:

Being new to the whole bugzilla thing, but excited about this feature - is someone up for publishing pseudocode/specification for this feature so we can all review it to make sure it meets our needs?  Im all for pledging, but only if this feature as implemented will meet my organization's needs.... 

I've read this thread but I havent seen a specification for this feature - did I miss something?

for instance ---  we have 50,000 users at my university - so we'll no doubt have a read-only LDAP address book for the whole campus - but it would be great to have a read-write ldap address book for the local organization within - so this has a lot of implications:  multiple LDAP address books must be usable simultaneously, they should be prioritizable (like a search path), is locking needed on the writable LDAP db's?  Since an org could have a 100 users updating it simultaneously with different "John Smith" entries -how is that handled? .....  or is the pledge for a very simple one user, one-LDAP Server design - where each individual has their own LDAP server "OU" all to themselves?

If we're serious about this feature, perhaps we should get a design doc started.

-Matt
(In reply to comment #74)
> If we're serious about this feature, perhaps we should get a design doc
> started.

Its good idea to start discussions off Bugzilla, better place for that is mozilla.dev.apps.thunderbird newsgroup.
Since the http://www.pledgebank.com/LDAP-AddressBook did not make it target by far. We can see pledgebank is not the way to go for these kind of feature requests.

I will create a list of all my feature/bug reports in the beginning of this week. Make a project document of them and present them at 6 march on the MozillaCamp in The Netherlands. I already talked about some of the feature request to get a fund for it. But we need a capable developer!

https://wiki.mozilla.org/MozCamp/Utrecht

Best regards,

Jelle de Jong
OK here's a start on a Work-around --

Having been so frustrated at the utter lack of progress in almost a decade (!) on this bug I at last wrote a work-around -- a "fake" LDAP server that reads a Thunderbird address book, monitors it for changes and re-reads it as necessary, and shares it out talking the LDAP protocol.  It's written to accept plugins, so it could just as well share out Wordpress or OSCommerce addresses, or whatever you like.  It's a long way from finished, but it is a reasonable proof of concept.

http://blog.wlindley.com/2009/10/share-thunderbird-address-book-via-ldap/

Will we have to wait another decade to actually get Thunderbird editing "real" LDAP address-books?
My current work-around is similar: http://www.fefe.de/tinyldap/
except the format is slightly different:
sed -Ee '/^modifytimestamp:/d;s/^objectclass:/objectClass:/'

Another decade? I hope not!
Is this feature planned for the next Version of Thunderbird? It would be great, if this will be built in.

Kind regards
Andreas
subscribe.
After months of search and tests on everything I could find, I finally found a really nice TB plugin that does it: LdapWR
https://addons.mozilla.org/fr/thunderbird/addon/91000

In fact, you point a local addressbook to the LdapWr plugin and it syncs it on demand. 
Quite ingenious coz that way you can create lists in your addressbook, things you can't do with a real ldap addressbook. But not yet, as it tries to sync the list and that creates few problems.. But I told the dev and now I cross my fingers :)

There was a error when trying to configure it (that's why I abandonned it the first time..), but the dev gave the solution.. quite simple. I put it on the plugin page.

If that plugin can add few options like, ie an auto sync, that can be the one.
(In reply to comment #83)

> If that plugin can add few options like, ie an auto sync, that can be the one.

Thanks for hinting at this add-on!! I use it now. The add-on shows that this feature really can be implemented!

There is, however, one general downside with the approach. If you e.g. only support the "inetorgperson" class on the server, the some unmapped fields are always available for editing are available in a local addressbook, while other mandatory fields like "sn" are not always present. "Fixing" those inconsistencies using mapping rules in an addon really makes things complicated.

I think a closer integration like in KDE Kontact is really necessary. Maybe the developer of the addon wants to take on the job. I would even donate a small amount of money and reading earlier comments other would do as well.
I tried that plugin but it doesn't seem to want to work very well with the Windows version of Thunderbird. In looking at this bug, I find it hard to believe that it's been open for the last... 

Ten years? Am I reading that right?

This is one solution that would truly make Thunderbird the best choice for small businesses. I have numerous clients who are interested in centralizing their address books and I have been struggling to put together a suitable solution for them. What would it take to get this rolling - perhaps some donations? 

Ten years..
As a strong supporter for editable LDAP support I am going to shoot out.

The many different schemes and implementations of LDAP address books are making it very difficult to make a good LDAP contacts book that syncs with multiple clients. We need a contacts standard, and guess what. This exist it is called CardDAV. So for this open standard for contacts to work we need a CardDAV server and a client. (http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-10)

The CardDAV server is production ready and can be found here: http://wiki.davical.org/w/CardDAV

The Thunderbird client can be found here:
http://www.sogo.nu/english/downloads/frontends.html

The integration with Thunderbird is still bad. I would like to suggest dropping LDAP and creating a good native CardDAV server implementation that integrates with Thunderbird.

Is this something the Thunderbird developers would like to do?

There is work in progress to make a CardDAV client for the android platform, the CalDAV plugin for android is also being improved. The iPhone already has native CardDAV and CalDAV support.
"The many different schemes and implementations of LDAP address books are making
it very difficult to make a good LDAP contacts book that syncs with multiple
clients."

Hi, This is not really true. There are a very few number of really useful LDAP schemas for contacts, the main one being inetOrgPerson, and the schemas it depends on. A properly written LDAP schema will co-exist with all others, and all the client needs to do is to be informed of the available schemas, which as far as I understand, is something the client can interrogate newer LDAP servers for (LDAP v3: browsable schemas, I think).
This bug is 7 years old, and still there's no work on it.  I set up an ldap directory today to share contacts across computers, and I find out there's no write support.  What's the point of a read-only address book, where I have to log into my ldap server to actually add someone?
(In reply to comment #88)
> This bug is 7 years old, and still there's no work on it.  I set up an ldap
> directory today to share contacts across computers, and I find out there's no
> write support.  What's the point of a read-only address book, where I have to
> log into my ldap server to actually add someone?

Well... adding someone is the responsibility of the Admin anyway. I would never allow any of my users full write access to our entire Company Directory...

That said, it would be nice if each user had the ability to update their own entry...
> Well... adding someone is the responsibility of the Admin anyway. I would never
> allow any of my users full write access to our entire Company Directory...

No, but there is not reason not to have private address books in LDAP as well. We have a system where each user has an address book under their own user entry, that they can edit and no one else can see.
(In reply to comment #90)
> No, but there is not reason not to have private address books in LDAP as well.
> We have a system where each user has an address book under their own user
> entry, that they can edit and no one else can see.

Point taken, and I agree... but there are other bugs I consider more important (full GPO support, fix the occasional local store corruption of attachments, bringing back the old Quick Search widget, etc) right now...
"Point taken, and I agree... but there are other bugs I consider more important
(full GPO support, fix the occasional local store corruption of attachments,
bringing back the old Quick Search widget, etc) right now..."


Maybe, but that's the kind of thinking that leads bugs to stay open for ten years at a clip. It's not like this is a brand-new thing someone asked for a couple weeks ago.


"Well... adding someone is the responsibility of the Admin anyway. I would never
allow any of my users full write access to our entire Company Directory..."

In some situations this would be true - but in some cases this is exactly what we need to be able to do. I have a client who is extremely interested in a central address book - a boss and secretary team who both can be trusted to administer their central address book but we have no way of putting this together in a simple way for them. I showed them the PHPLdapAdmin program and like many "users", they were intimidated by the unfriendly interface and learning curve that is present in so much open source software. They would prefer to just be able to add and delete entries from within Thunderbird, which they are both comfortable using.
(In reply to comment #92)
> that's the kind of thinking that leads bugs to stay open for ten
> years at a clip. It's not like this is a brand-new thing someone asked for a
> couple weeks ago.

Neither is full GPO support... ;)
I absolutely 100% agree with comment #92, Like, +1 etc. We can keep our email on a server and have shared access to shared folders, using e.g. dovecot IMAP, so why not the same capability for address books? I am considering SOGo and its plugin but I think it's a shame I can't use the more obvious and very much more lightweight LDAP.
(In reply to comment #89)
> Well... adding someone is the responsibility of the Admin anyway. I would never
> allow any of my users full write access to our entire Company Directory...

But LDAP entries should be write-protected by super-user (ie manager) id and password. At least if it's correctly setup...

But then, TB address book interface has to be changed to let user input some credential, and this would require to open another new bug, and possibly another ten years :D
(In reply to comment #95)
> But LDAP entries should be write-protected by super-user (ie manager) id and
> password. At least if it's correctly setup...

It depends on the LDAP server configuration. You could create a group of trusted users with permissions for writing into the addressbook. 

> 
> But then, TB address book interface has to be changed to let user input some
> credential, and this would require to open another new bug, and possibly
> another ten years :D

Now, when you connect TB to a LDAP addressbook (in read-only mode) you already give your credentials for accessing LDAP. So this is already done.
As stated in comment #66, the code for writing to LDAP was committed three years ago (see bug 356208), so debating back and forth on the issue is pointless. 

- If you want to play with the code, recompile TB with MOZ_EXPERIMENTAL_WRITEABLE_LDAP defined. 

- If you want to see this bug report closed for good, what still needs work is refactoring the addressbook UI code to react to asynchronous events, because unlike other addressbook backends you only get the success/failure status once the server responds.

No more noise please.
I'd like to tackle this bug. Can you E-mail me more details on what needs to be done and the relevant code in which to start looking? (I've never contributed to Thunderbird before but am an active contributor to Mixxx in which we've done a good deal of code refactoring.)
It's great to see ambition around stuff like this.  That said, I would strongly recommend that this not be the first Thunderbird bug that anyone tackle, no matter how strong of a coder, because for a whole bunch of reasons, I would expect that scenario to lead to frustration.

Have a look at <http://bit.ly/gIMIhi> for a list of bugs that are more tractable to start.  If any of those strike your fancy, please send me a mail, and I can help you get started.
datapoint: 36 people like this idea at http://getsatisfaction.com/mozilla_messaging/topics/write_access_to_ldap_addressbook
URL: http://getsatisfaction.com/mozilla_me...
Depends on: tb-enterprise
Whiteboard: Please: No useless comments → [Please: No useless comments][gs]
(In reply to comment #100)
> datapoint: 36 people like this idea at
> http://getsatisfaction.com/mozilla_messaging/topics/write_access_to_ldap_addressbook

now ~50.

There is a posting at http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/a70b451b042de5e7?pli=1 entitled "Support for write LDAP" which might be used to discuss how to move this bug forward.
Blocks: tb-enterprise
No longer depends on: tb-enterprise
Just one contrarian thought (and sorry for ranting on bug, but I don't think it much matters exactly in this case). Yes, I was waiting for resolution of this bug for years holding my breath when it happens. Aside from Trustedbird which made some movements on the LDAP side of Thunderbird support, I don't see any explosion of popular interest in LDAP. Moreover, the rigidity and incompleteness of most LDAP schema (and compatibility issues when using non-standard ones) started to get on my trust in LDAP itself for normal user (i.e., not multi-billion corporate global corporation).

Could we switch our attention to support for CardDAV? (https://bugzilla.mozilla.org/buglist.cgi?quicksearch=carddav)

In the end I have to admit that I am turning towards comment 86 and closing this as WONTFIX.
I would say that the lack of popular interest is due to the lack of application support, not the other way around. I also find that CardDAV has even less popular support right now, whereas many fax machines and telephones support LDAP. Yes, LDAP can be a pain to set up, but thinking that the number of available schemas as a negative is wrong. Properly written schemas (and there are many) overlap each other without causing problems, and the whole point about LDAP is that it can support many different applications, so the data is in one place, and only in one place. All of the complaints about user permissions, and difficulty in setting up are just down to a lack of experience with the protocol.
LDAP, CardDAV...  both are sufficiently open, imo.  I don't know much about either's strengths or weaknesses.  I don't much care which one becomes workable first.  I'll use either.

oh, and I'll just complain a lot until someone else solves this for me.
(In reply to comment #103)
> I would say that the lack of popular interest is due to the lack of application
> support, not the other way around. I also find that CardDAV has even less
> popular support right now, whereas many fax machines and telephones support
> LDAP. Yes, LDAP can be a pain to set up, but thinking that the number of
> available schemas as a negative is wrong. Properly written schemas (and there
> are many) overlap each other without causing problems, and the whole point
> about LDAP is that it can support many different applications, so the data is
> in one place, and only in one place. All of the complaints about user
> permissions, and difficulty in setting up are just down to a lack of experience
> with the protocol.

What I meant about rigidity of schemas was, where's a schema which would be widely used (at least Evolution, Thunderbird, Outlook, Apple Addressbook, Android something, iPhone something ... not knowledgeable enough about these two mobile platforms), which would allow storing and querying now required addresses (bunch of various types of phones ... think at least about multiple home phone, office phone, mobile phone, VoIP phones; various IM contacts (Yahoo, Jabber, MSN, Facebook chat), Twitter/IdentiCa/Facebook)?

Also, which of the widely used services (let's say Google, Yahoo, AOL, MSN, and similar, or free server software) support LDAP? I know only about Zimbra and RO support for Fastmail.fm. Whereas everybody and their dog seemed to at least work on supporting CardDAV and many already support (e.g., just mentioned Zimbra).
Sad to see this unresolved for 10 f***ing years now.
The reason it stays unresolved is because people make comments like "no more noise please" to folks who are discussing it, or folks that offer to work on it and ask for direction are told "don't work on this, here work on this instead". 

The indecision and lack of any real leadership is why opensource will never become mainstream. 

I also agree that the reason there is little interest in the LDAP system in general is because it doesn't work, not because people don't have a need for a centralized address book that is easy to manage. I came here looking for a solution for one of my clients, but after seeing that it's been an ongoing request for ten years that has largely been ignored we ended up implementing an exchange server for them. Not necessarily the route I wanted to go, but there was no choice. 

Anywho, this is my last comment here as I am sure that I will once again be told to "stop the noise". Thanks for that, btw.
Relax, guys. Despite what I've been told, I am still going to try to fix this myself. I just haven't had time since I've been very busy with client work. I expect to start working on it in in earnest the next couple months. No telling when I'll get done since I have alot to learn about the codebase, but just know that someone has it on their nearer term radar. :)
Cheers! There might even be some money in it for you. There have been pledges in the past, from me and others.

If you need any help with LDAP or LDAP servers, let me know. We have masters and slaves and all the usual schemas, plus a couple of our own. Referrals can be especially nasty to handle, depending on the LDAP library (e.g. I think the C library is broken. I have been following a bug through from PHP).

As to the "Stop The Noise" remarks - Rock 'n' Roll ain't noise pollution; It's just Rock 'n' Roll.

Marco.
Since this is "my" bug, I'm quite proud of the fact that I reported what must be one of the oldest bugs that is still relevant, still undergoing active debate and still not fixed after almost 10 years.

But I use LDAP for my addressbooks, and I would be more than happy to test beta-builds to help you fix this.

When it comes to schemas, I believe we would come a long way if we could at least begin with the most relevant attributes from inetOrgPerson.
It will not be the perfect solution for all, but at least it's a start, and someone could create a new bug to extend the schemas, rename attributes and so on later.  

Just imagine this bug being fixed before June this year - that would be a happy anniversary for all of us.
As I'm, after Ola, one of the oldest "supporter" of this bug let's have a 10th anniversary party ;-)

I raised this question quite a while ago (also nearly 10 years - still open - still valid ;-)  
So see bug 116692 which deals with "Define official Mozilla LDAP schema extension"
CardDAV / LDAP write support is a commonly requested feature amongst many users, especially given the rapid increase in smartphone usage (iPhone, Android etc.) for example SOHO users that have increasing needs of synchronization between various devices. The problem is that almost all of them + many system administrators do not know that there are a bugzilla voting system to indicate the need for such features - IMHO this creates somewhat biased input about feature prioritization. 

I would say that this issue in reality should be given a significantly higher priority. Otherwise Thunderbird is a very competent product, proper CardDAV/LDAP write support (combined with Lightning for Calendars) would mean that Thunderbird would become a much more attractive alternative to MS Outlook also in the corporate world and for users with multiple devices to sync.
I agree with Thomas. The importance of this feature is probably underrated. Also the need to register in order to being able to vote discourages people even further.

Sharing the address book between two computers running Thunderbird is a very simple and common task. But I did not find a solution for it. The SyncML approach by Funambol does not work with TB 3 and the LDAP implementation lacks write support. Currently the only way seems to be creating a gmail account and use one of the add-ons that sync with google. But I prefer hosting the data myself and using free software and standard protocols. I'm sure there are more than 347 TB users with the same opinion...

Matthias
Surely. 
Allone mor than 500 users in the company I work in - the lack of this feature excluded the use of TB here, and at my home too.
I must admit I was surprised to learn that TB could not write to an LDAP hosted address book, but not as surprised to learn how old this bug is.

This would be a more worthwhile enhancement to TB as opposed to "clever" features that guess the wrong settings and prevent correction when creating email accounts.
Wow, I couldn't believe it when I saw that this bug was reported in 2001! TB is lacking a major feature now with not being able to write, edit, delete an LDAP hosted address book. Full LDAP/CardDAV support is really required these days with increase of mobile devices using PIM apps. I'm not interested in syncing with Google or other public cloud based services so really need LDAP or cardDAV support in TB. I tried setting up a Funambol server but that doesn't work with TB5 and it seems development on the extension has virtually stopped.
Hi,

I have just found this bug entry and I can only agree that probably thousands of people need a reasonable sync method for thunderbird address book contacts.

Just think of thousands of people in medium-sized companies who are using Thunderbird and Firefox instead of Microsoft Outlook and Internet Explorer. I bet many admins are also willing to support Thunderbird but the missing contact sync option is a show stopper to this issue. CalDAV with Lightning was certainly a big step into the right direction.

It seems to me that CardDAV gets more and more attractive over LDAP for the contacts issue and personally I prefer this because using it with CalDAV servers like davical makes the setup a lot easier for the standard pc user in the private sector. It also works perfectly with android systems and Apple products.

There is a bug entry which addresses the need for CardDAV support in Thunderbird. Unfortunately no developer has commented on the CardDAV issue yet. Is there a way to get the devs attention for this feature?

https://bugzilla.mozilla.org/show_bug.cgi?id=546932

I would appreciate if one of you could help to get at least something done in this direction.

Since the SOGo addon (to my knowledge the only way to get CardDAV support in TB) is not compatible with TB5 and TB6 anymore things got worse ...
(In reply to intrinsor from comment #117)
> There is a bug entry which addresses the need for CardDAV support in
> Thunderbird. Unfortunately no developer has commented on the CardDAV issue
> yet. Is there a way to get the devs attention for this feature?

Please do not cross-post on bugs, it only serves to confuse what individual bugs are about. Bugzilla is not a discussion forum as such, it is a place where folks can work towards fixing actual bugs, we have other communication channels available: https://wiki.mozilla.org/Thunderbird/CommunicationChannels
Thunderbird is cool.
But....what would make Thunderbird REALLY special ?
What does the 99,9% email client lack ?

LDAP WRITE SUPPORT

please, save me from PHPLDAPadmin 
please, make it happen

I offer me and my company as beta tester.
As more users/small businesses start using LDAP, being able to ADD/EDIT LDAP entries becomes more important. I agree with Naoto on this.

What about Google Code of Summer? Can´t one submit this as an idea?
Emite,

  LDAP may be a good centralized authentication system, but LDAP as an addressbook-Server is dead, dead, dead.

  The upcoming technology is carddav and thunderbird should implement as first-class carddav client,

   Wolfgang
Wolfgang,
I strongly disagree with your suggestion. As you stated above it is an upcoming technology (which does not have a RFC yet) but LDAP is a solid "framework" that is currently supported by all vendors. One should stick to the technology already implemented and enhance it instead of the wild chase for new. That is why, from my point, Open Source often fails to comply with the user needs. For example PHP-Myadmin became a de-facto default administration tool - because they were not chasing for HTML-5 and AJAX and and and, but build the core functionality and enhanced it. This is what other open source developers should consider - not chasing some new developments but enhance core/basic support of standards and protocols - then OS would be much more popular (IMHO). Why do you want to have a car with a flat tire, but radio with MP3 support instead of a proper car? Sure you will get somewhere with a flat tire but...
This is not an either/or option. Yes, it would be nice if Thunderbird supported CardDav, but virtually nothing out there supports it yet, whereas in my office, today, (and since about 2005) I have been able to access my LDAP address book from the fax machine, network scanner and IP telephones, as well as all of our email clients.

BTW: Naoto, have a look at Contagged, if you want a web-based LDAP address book.
I too think it's not a either/or option, but we should have both.

LDAP is a standard for addresses in enteprises, and here you usually have other frontends to edit the ldap directory.

Cardav is realy the standard for address stuff in the internet, and it has a RFC http://www.rfc-editor.org/rfc/rfc6352.txt
No more noise. This bug is to make LDAP address books editable. Discuss the merits of that elsewhere please.
(In reply to Sean M. Pappalardo from comment #125)
> No more noise. This bug is to make LDAP address books editable. Discuss the
> merits of that elsewhere please.

Agreed. So to that end, what is the status of this ELEVEN year old bug? Is anyone in Mozilla (or elsewhere) going to work on it?
I don't care. I've switched to a different mail client at the beginning of the last decade. 

If there is any reason not to use open source software - just take a look at the history of this bug.
I don't really want to derail this bug with OT discussion (not that it's going anywhere without it) but...

@Tom, I'd like to know how the lack of action or resolution here has anything to do with it being "open source software"?

On the contrary, the fact that it is open source software enables *you* (or anyone for that matter) to fix the bug if it's bothering *you* enough to get off your ass to fix it.

If this were closed source software and the bug was not being fixed by the developers, you would have no ability to fix it yourself and would have absolutely no choice but to suffer through it.  Now how is that a better model?

You seem to be making a strawman implication that just because software is closed source that all reported bugs get fixed.  I think you, I, and everyone else knows that that is simply not true.
My alternative is to use the evolution e-mail client (Linux) which allows to edit LDAP contacts. It's a really great Outlook alternative.

The Windows version is outdated and not really good, but if there is as much interest as I see here (11 years and insisting!), I'm sure it won't last 10 years to port the latest version.

See:
https://live.gnome.org/Evolution
http://evolution-win32.sourceforge.net/

Otherwise, only Exchange or SoGo offer similar functionality. It's too bad for Tbird, I was willing to give it a try.
OK.  What does it take to do this?  Give me a little info on some of the challenges here and I'll do it.
I think the logic should be more or less similar to IMAP folders:  Keep a local copy of one or more address books, sync the local and remote copies when getting back online.

Having the possiblity to allow read or write access to selected identities would be great.
Hi
First of all you will need to retrieve the LDAP server schema so that you can work out the field mappings. As I understand, any server supporting LDAP v3 can be interrogated for it's schema. As an example PhpLdapAdmin has a schema function you could look at. Then you need a configuration set-up to map ldap attributes to address book fields. There are only a couple of ones in common usage, so I would stick with a default of InetOrgPerson (and the attributes it depends on) and have a control panel that allows the values to be customised. Would be nice if you could roll out your own mappings by distributing a small file as well.
Once you have that in place, then all I think you need to do is to add a standard TB address book that sync's with the LDAP server. LDAP has a hidden time stamp for every single record, so if you save that value when you last synced, you can use it to run a query. The same process can be true for updating back to the server (you might have to add a "last modified" function in Thunderbird). Then all you need is a conflicts resolution mechanism (eg server wins, or duplicate record, etc). One final point, you need to be able to optionally support referrals, and a lot of the C and PHP examples are bogus. Look in the PHP function examples on php.net for some history about that. Basically the docs are misleading.

Now, if you want to be _really_ clever, look at how syncrepl and the old slurpd in openldap works. If I was looking at doing this from scratch, I would set up a "slave" copy of the LDAP database using the pull mechanism used by syncrepl, make offline reads from that from underbird for speed, and then intercept any writes, and use the push mechanism of slurpd, which could queue writes until the server became available.

Good luck. Let me know if you need a testing environment. We have lots of LDAP servers!
I'm wondering if using the Thunderbird plug-in architecture might be more expedient route?
It's not easy to find the status updates among the noise in this bug, but have a look at comment 66 and comment 101, and the "Depends on" list at the top of this bug: the open dependencies show what needs to be done, and the resolved dependencies show what's been done already to fix this bug.

Looks like the UI is one of the key aspects to be done.
Thanks Steffen, and Marco.  So according to these comments, this code has been mainlined into the Thunderbird trunk?
Hello,

I think something else important to think while doing this is to be able to manage the mailing lists feature (add / remove lists & members).

An idea is to have a (separate / sub) branch where entries use the objectClass 'groupOfNames'. That should do the trick.
'groupOfNames' is defined in core.schema.

Good luck.
Maybe we are looking at this problem the wrong way.

I have a suggestion as, due to the complexity of this matter, this bug won't be fixed soon.

This should remove the work load from TB devs and everyone will be able to have its writable LDAP address book that suits his need (specific schemas, rights, ..).

When creating a new LDAP address book, TB should offer the possibility to enter an address to access / modify / delete the data. Not a LDAP address but a server script address (ie: http://localhost/LdapCardManagement.php).

And it will be to the admin to put the right script (python, php, java, ..) at that address to manage the queries from TB and return what the right answer.

The important thing to do from TB devs will be to clearly defined what params are used in differents situations and what data and data format it expects in return:
- Query one full card,
- Query a search expr,
- Modify one or several cards,
- Delete one or several cards,
- .. the same for mailing lists...
- As result, TB need the data in json format or ...

That way, it will be easy to manage ourself the "writable" part of the address book.

LDAP servers are used mainly by admins, not mister everyone. So those who will configure this kind of address books will understand what they have to do.
A bit the same way it works with TB and the SOGO Connector plugin to have DAV address books available.

I'm sure in no time, we'll find good exemples of classes to manage that (like Radicale for DAV address books).

I hope it was ok to post this here (very sorry if not).
It's the best place, I think, to have lots of LDAP fans who would dream to have a solution to this problem.
And if we manage to realise this, you'll be able to close this very old bug :)
As comment #120 mentions, what about Google Summer of Code? I am assuming it could be added to the wiki here: https://wiki.mozilla.org/Community:SummerOfCode14:Brainstorming#Thunderbird (or substitute 14 for whatever the current year is). I don't have write access to that page, or else I would have added it myself.

It looks like a roughly appropriate size for eight weeks of full-time coding. Correct me if I'm wrong.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.