118270 - When creating a list, it should be able to autocomplete against other addressbooks

Status: RESOLVED WORKSFORME

(MailNews Core :: Address Book, enhancement)

Description

[Ninoschka Baca]

Overview: When creating a mailing list should it autocomplete again the current
address book or others such as the collected address book.

Steps to reproduce:
1. Select New List button
2. Type in the name of the list
3. Tab to the first address area
4. Type some text (user1)

Actual Results: It trys to autocomplete (i.e. [e-mail])

Expected Results: What address books should be used while it's autocompleting?
The current one or others?

Comment 1

[jglick]

It would be nice if it autocompleted against all available ABs.

But I believe all the addresses included in a Mailing List need to belong to the 
parent AB (this still true?). So, any cards in other ABs, not in the Mailing 
List's parent, would need to get added to the parent AB as well.

Comment 2

[scottputterman]

I think we decided the answer was that it should autocomplete against everything.

Comment 3

[Mark Banner (:standard8)]

*** Bug 299946 has been marked as a duplicate of this bug. ***

Comment 4

[Thomas D. (:thomas8)]

Wayne or anyone, can you explain what this bug is trying to do? (you turned this into an RFE in 2010).

This bug is currently not actionable. The description of this bug is incomplete because Actual Results don't state against which AB(s) mailing list autocompletion actually occured at the time of filing this bug. Expected result presents an OR-question with two alternatives so it's ambiguous, same for summary.

From comment 2, I suspect when this bug was filed, mailing list properties dialogue only autocompleted against parent AB of mailing list. But now (TB31) it autocompletes against all ABs, which allows creating lists with address taken from any AB, however creating duplicate cards in the list's parent AB. The design is fundamentally conceptually broken beyond redemption. So I'm not sure what this bug wants. Simply limiting autocomplete to the parent AB would prevent creation of pseudo "cross-AB" lists, so that sounds wontfix. Otoh, given that mailing lists are currently bound to a single parent AB (instead of floating freely), some users are surprised that non-parent ABs are searched, as seen in scenario of duplicate Bug 299946 Comment 0 having office AB vs. private AB.

These days, we'd probably want to give users a choice as to which ABs should be consulted or not, along the lines of bug 220370. So whatever we want here as a (temporary) improvement before new AB will eventually arrive, needs to be spelled out. Otherwise this should be closed.

Comment 5

[Thomas D. (:thomas8)]

We could add a simple dropdown list in the Mailing List Properties dialogue:

[A] Basic AB Selector
Search for addresses in: [All Address Books |v]
                         |Personal Address Book |
                         |Custom Address Book   |
                         |Collected Addresses   |

So in a basic version, that would allow users to chose between ALL ABs or any ONE single AB.


[B] Advanced AB selector
Or, more advanced and more work, we could allow users to pick their favorite selection of ABs for autocompletion:

Search for addresses in: [Select...     |v]
                         |[x] All Address Books     |
                         |[x] Personal Address Book |
                         |[x] Custom Address Book   |
                         |[x] Collected Addresses   |

(checking "All ABs" checks all ABs, unchecking single AB unchecks "All ABs")

In spite of the broken design, any of [A] or [B] would still make the process of creating lists more precise/efficient/less error-prone.

Comment 6

[Wayne Mery (:wsmwk)]

IMO we should not invest in fixing this under the current AB architecture. When the new addressbook comes around, the architecture should naturally not be not restrictive so that this is not an issue.

Comment 7

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #6)

IMO we should not invest in fixing this under the current AB architecture.
When the new addressbook comes around, the architecture should naturally not
be not restrictive so that this is not an issue.

The new addressbook has come around, but mailing lists haven't been touched yet so they are still conceptually flawed as ever (Bug 757736).
However, notwithstanding the lack of clarity in this bug (as I explained in comment 4), with the current summary this cannot be wontfix because it was already implemented when this bug was wontfixed. So I guess that makes it worksforme, kind of.

Fwiw, my comment 5, while still valid atm, and against which the wontfix of comment 6 was probably directed, would have been better off in its own bug, rather than trying to morph this.