This is a feature tracking bug for autocompleting email addresses in the compose window using LDAP directories

P4 per m/n staff mtg today

Moving all P4s out of beta2 to M17.

Phil found a way to weasel out of owning this bug. Reassigning.

[LDAP] in summary

LDAP to M30, nobody, helpwanted

Changing qa assigned to myself.

Taking this bug and removing helpwanted. It would be a really fine thing to land this for mozilla 0.9. The exact strategy to take for this has yet to be hammered out. In some sense, the more elegant way is to integrate LDAP into the addressbook first and then let the existing addressbook autocomplete work. But realistically speaking, the addressbook is currently tightly wired enough to Mork and addressbook autocomplete is likely to have dependencies on how long it may take to return results. So as a way land this feature sooner rather than later, my suspicion is that the right thing to do may be to implement nsI(Ab)AutoCompleteSession ourselves. The cleanest way would be if it's possible to run multiple autocomplete sessions on a single textbox simulataneously. Not sure whether that's currently possible. More investigation to follow; comments invited.

Assign to Hong's group

Moving to my netscape account.

setting qa to yulian@netscape.com

Untargetting, since this is a meta bug.

Hi there, Any progress on this, is this available in 1.5. My entire company's addressbook is on the LDAP. We would like to put our clients addresses in the LDAP too to share out as a global addressbook but it can't be done because the addresses can't be displayed when I click on the LDAP under address book. BTW i am using 1.3. The address would only appear when I key it in in the search field.

Hmm. I'm using moz-mail 1.6 and LDAP auto-complete for mail compose window is working great! In the addressbook, LDAP lookup works fine also when you provide search parameters. Reading the comments, perhaps this bug should be closed and a new one opened for auto-loading LDAP entries to the addressbook? Or, perhaps I don't understand this bug? Regards, John

This is a tracking bug. It exists for purposes of its dependency tree. Click the "Show dependency tree" link to see that.

I know this is implemented (there's an option for this, for Christ's sake), but I'm noticing that it doesn't actually work very well. Or rather it either works fine (sometimes) or just not at all (most times). I've been unable to find out why, up to now. Do I open a bug for this (I couldn't find one) or is this the correct place for this?

Yes, that would be a separate bug. This is a meta bug used for tracking the dependent bugs.

Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.

The remaining dependent bugs seem to be mostly related to performance only. So, in the sense of "bug", they should not be considered "blocking". This bug at the current stage seems to be more an enhancement than a bug. OTOH, some dependent bugs are not really or fully relevant. To name a few: Bug 75999: Does the resolution of this bug really have impact on autocomplete? Bug 80803: This is not only useful for LDAP, but in general situation. Bug 126022: This is about collected email addresses. Not autocomplete.

None of the dependent bugs have been updated since 2008 ... can this one be closed?

As this is a tracking bug, it's not correct to close it, well, at least personally, I would vote against closing it.