1154790 - Want to use Notes field for tagging of contacts, but autocomplete of addresses does not search Notes field content

Status: RESOLVED DUPLICATE of bug 457736

(Thunderbird :: Message Compose Window, defect)

Description

[peter.eversden]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
Build ID: 20150330093429

Steps to reproduce:

My Notes field for people in my address book contains words which I can use if searching my address book with a plug-in but I want Thunderbird new message window to look for Notes field content when autocompleting an address.


Actual results:

Only names are used by Thunderbird for autocomplete.

Comment 1

[Thomas D. (:thomas8)]

Peter, thanks for that proposal!

(In reply to peter.eversden from comment #0)

> Steps to reproduce:
> 
> My Notes field for people in my address book contains words which I can use
> if searching my address book with a plug-in but I want Thunderbird new
> message window to look for Notes field content when autocompleting an
> address.
> 
> Actual results:
> Only names are used by Thunderbird for autocomplete.

Expected results (by reporter):

Recipient autocomplete should also search "Notes" field of contacts.


The two current autocomplete searches are hardcoded (which we want to change in bug 118624):

Initial autocomplete search:

http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#385
> 385       let modelQuery = "(or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)" +
> 386                        "(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)" +
> 387                        "(and(IsMailList,=,TRUE)(Notes,c,@V)))";:

Secondary autocomplete search to reduce the inital result set:

http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#224
> 224   _checkEntry: function _checkEntry(aCard, aEmailToUse, aSearchWords) {
> 225     // Joining values of many fields in a single string so that a single
> 226     // search query can be fired on all of them at once. Separating them
> 227     // using spaces so that field1=> "abc" and field2=> "def" on joining
> 228     // shouldn't return true on search for "bcd".
> 229     let cumulativeFieldText = aCard.displayName + " " +
> 230                               aCard.firstName + " " +
> 231                               aCard.lastName + " " +
> 232                               aEmailToUse + " " +
> 233                               aCard.getProperty("NickName", "");
> 234     if (aCard.isMailList)
> 235       cumulativeFieldText += " " + aCard.getProperty("Notes", "");
> 236     cumulativeFieldText = cumulativeFieldText.toLocaleLowerCase();
> 237 
> 238     return aSearchWords.every(String.prototype.contains,
> 239                               cumulativeFieldText);
> 240   },

Notes field is currently only searched in the special case of mailing lists, where it's misused as description.

In bug 118624, I advocated for and began adding more fields to the default searches of AB/contacts side bar AND recipient autocomplete. My tentative list of fields does still *not* include the Notes field (except for mailing lists):

"(or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)(and(IsMailList,=,TRUE)(Notes,c,@V))(Company,c,@V)(Department,c,@V)(JobTitle,c,@V)(WebPage1,c,@V)(WebPage2,c,@V))"

However, bug 118624 comment 50 suggests adding more fields to the *autocomplete* search *in a new, separate bug* because of potential performance implications (where we've already been facing problems with autocomplete perf). So adding fields for autocomplete might not happen at all in bug 118624, and "Notes" field is not planned for inclusion even if we were to add fields.

But bug 118624 wants to realise the model searches as user-configurable prefs, allowing you to add any search fields of your choice in the advanced configuration of TB (perf impacts yet to be explored), which is a good way of addressing this RFE.

Having said which, I'm very skeptical against including "Notes" field in the *default* set of fields to be searched by recipient autocomplete, because it might have unintended side effects for users actually using this is field for potentially extensive *Notes* (as opposed to your proposed non-standard use which is more like tags). Pls find my detailed explanation in bug 298438 comment 24.

As a workaround, I suggest you can use the nickname field to add those search words (tags) to your contacts, so they won't occur in your message but you can still use them for finding contacts. You can still practically retain the nickname functionality by adding a truly unique nickname at the beginning of your tags list in nickname field, like this:

Display Name: "John Doe"
Nickname: ":jd tag1 tag2 tag3"

Then you can use ":jd" as a unique nickname to retrieve exactly that contact; or you can use any of the tags, even in combination, to narrow down the result to only those people matching the tags.
E.g., you can search for "tag1 tag3" to find all people having "tag1" AND "tag2" set in their nickname field.

Per bug 298438 comment 24, I'm inclined to wontfix this idea for the default settings.

Comment 2

[Thomas D. (:thomas8)]

If anything, I'd rather include the fields Custom 1, Custom 2, ... Custom 4, but essentially (as explained in bug 298438 comment 24) they still come with the same doubt if user really wants them to be searched for recipient autocompletion (where the goal is to find a *single* contact, not a group of contacts based on common tags).

I believe something we could more easily do in the current (old) infrastructure of the AB is to add a "Tags" or "Search Words" field to the 'Contact' or 'Other' Tab, to allow adding freeform space or comma-separated words, which would then be explicitly and transparently included into any searches (AB quicksearch/contacts side bar, recipient autocomplete).

Comment 3

[:aceman]

The Notes field is searched but only for mailinglists so far.

Comment 4

[Thomas D. (:thomas8)]

(In reply to peter.eversden from comment #0)
> Steps to reproduce:
> 
> My Notes field for people in my address book contains words which I can use
> if searching my address book with a plug-in but I want Thunderbird new
> message window to look for Notes field content when autocompleting an
> address.

"words which I can use... when autocompleting an address"
That's really search words aka tags for contacts.
Which makes this bug a duplicate of

Bug 457736 - Inline contact editor (and Edit Contact properties dialogue) should support freeform contact tags (single-row simple text input field)

I've started campaigning to breathe new life into that bug.

The larger brother of Bug 457736 is bug 75711, which currently has 12
duplicates and 25 votes.

(In reply to Thomas D. from comment #1)
> Per bug 298438 comment 24, I'm inclined to wontfix this idea for the default
> settings.

FTR, the particular idea of this bug 1154790 is wontfix because we cannot safely assume that users want the potentially extensive, free-style content they added to Notes field to be searched when searching for a single contact in recipient autocomplete. It would yield a lot of false positives, which really annoys users as seen in many bugs around recipient autocomplete.

Peter, thanks for sharing the idea which made me refocus on Bug 457736 which would be really cool to have...

Comment 5

[Thomas D. (:thomas8)]

(In reply to peter.eversden from comment #0)

> My Notes field for people in my address book contains words which I can use
> if searching my address book with a plug-in

Peter, could you pls add the link to the plugin you are using?(In reply to peter.eversden from comment #0)