User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Build Identifier: version 2 beta 2 (20070116) I would dearly like to see the search window in the upper right corner of the address book include organization along with name & e-mail. I have addresses for organizations in my AB where the person is irrelevant. A workaround is to put the organization name in the last name field, but it would be really nice to include org in the search (not to mention that it corrupts the data--only for the law is Walmart a person). Reproducible: Always Steps to Reproduce: 1. 2. 3. Could be a combined search of all 3 fields (name, e-mail, org) or a selection of name/email or org. I'd be happy with either

Confirming RFE.

Moving to Core Address book as its an enhancement worth considering for both.

Safari works like this ... ;-)

I cannot believe this feature is 2.5 years old... Is it really difficult to do? Maybe a good candidate for an extension?

I cannot believe that someone with your email address is asking why their free lunch hasn't been served yet :)

Hah! Thats a good one, and true enough... guess there really is such a thing under certain circumstances, seeing as I've been using lots of free software for a long time... But seriously - how hard could this be? Just add the field to the list of fields searched, and change the label from 'Name or Email' to 'Organization, Name or EMail'... like I said, seems like a trivial change, but being that ianap, I just wouldn't know...

Well, it all about config editor. preference name is mail.addr_book.quicksearchquery.format you need to change from: ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)) to: ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(Company,c,@V)) works for 2.0 and 3.0

Yep, found this workaround a while back, but still, this should be the default...

(In reply to Roman Barczynski from comment #8) > Well, it all about config editor. preference name is > mail.addr_book.quicksearchquery.format > > you need to change from: > > ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)) > > to: > > ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c, > @V)(Company,c,@V)) > > works for 2.0 and 3.0 Hello, please read Bug Bug 298438 discussion - the config that you are giving is related to contact sidebar plugin. I also thought it is built in function. Never the less if you have this plugin and you set preferences like you said it works. I have more fields added - ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(Company,c,@V)(Notes,c,@V)(Custom1,c,@V)(Custom2,c,@V)(Custom3,c,@V)(Custom4,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName,c,@V)(_AimScreenName,c,@V)(SecondEmail,c,@V)(WebPage1,c,@V)(WebPage2,c,@V)(WorkAddress,c,@V)(WorkAddress2,c,@V)(HomeAddress,c,@V)(HomeAddress2,c,@V)(CellularNumber,c,@V)(WorkPhone,c,@V)(HomePhone,c,@V)) which I think covers all fields.

(In reply to Charles from comment #5) > I cannot believe this feature is 2.5 years old... > > Is it really difficult to do? > > Maybe a good candidate for an extension? Neither can I :) Read bug Bug 298438 - I also comment on how slow the progress is on this issue.

(In reply to Szpak from comment #10) > (In reply to Roman Barczynski from comment #8) > > Well, it all about config editor. preference name is > > mail.addr_book.quicksearchquery.format > please read Bug 298438 discussion - the config that you are giving is > related to contact sidebar plugin. I also thought it is built in function. > Never the less if you have this plugin and you set preferences like you said > it works. Hi Szpak, I appreciate your continued interest in this matter... However, the information you provide here isn't correct and might confuse others, just as your Bug 298438 Comment 17. > mail.addr_book.quicksearchquery.format This preference is an *inbuilt* part of any default TB installation (no addons/plugins required) and can be adjusted as correctly described in comment 8, via Tools > Options > Advanced > General > Config Editor. Likewise, there's an *inbuilt* "Contacts Sidebar" which ships with default TB and does *not* require any addons. From composition window, use View > Contacts Sidebar (or F9 keyboard shortcut) to toggle visibility of the inbuilt side bar. The pref will change the behaviour for both, - main AB quicksearch (upper right corner) - composition's contacts sidebar (left side of composition window). This works for any version of TB including current TB24 (without addons), to expand the scope of AB searches or otherwise tweak the default AB search algorithm. The pref does not (yet) affect recipient autocompletion in composition's address widget. In Bug 298438 Comment 17, you talked about preferences which look like this: > contactssidebar.search_home;true All those prefs whose name starts with "contactssidebar" are *not* part of the default installation; so they must be part of an addon which you installed. Of course it's possible that that addon ultimately changes or overlays the inbuilt pref and thus will have the same effect. But no addon is required to change the AB fields which will be searched. > I have more fields added - > ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c, > @V)(Company,c,@V)(Notes,c,@V)(Custom1,c,@V)(Custom2,c,@V)(Custom3,c, > @V)(Custom4,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName, > c,@V)(_AimScreenName,c,@V)(SecondEmail,c,@V)(WebPage1,c,@V)(WebPage2,c, > @V)(WorkAddress,c,@V)(WorkAddress2,c,@V)(HomeAddress,c,@V)(HomeAddress2,c, > @V)(CellularNumber,c,@V)(WorkPhone,c,@V)(HomePhone,c,@V)) > > which I think covers all fields. No, that does *not* yet cover *all* fields, e.g. several chat contact fields are missing. The full list of fields can be found in my Bug 298438 Comment 20 (as of 2013-12-08). (In reply to Szpak from comment #11) > Read bug Bug 298438 - I also comment on how slow the progress is on this > issue. Szpak, it's certainly true that progress on this issue is slow, more so from your very limited perspective where this bug and bug 298438 are the only bugs you ever commented on, according to your profile [1]. But they're just one single issue out of 10,000+ open bugs and RFE's currently filed against TB and mailnews core. Pls consider that TB is open source, and it's now developed and administered almost exclusively by volunteers like me (including some Mozilla developers who sacrifice their spare time), because Mozilla is no longer actively funding the development of TB (but still providing the brand, server space, builds, bug management system etc. etc.). So you're using TB for free, and we're working on it for free, both of which unfortunately involves an element of "no obligation" as laid out in the rules for this bug tracker (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html). In bug 298438, you were trying to create the impression that I'm slowing down progress on this bug by asking too many or the wrong kind of questions. The opposite is true. I'm one of the very few people who have been actively, decidedly, and constantly driving bugs forward for years, and I come with a lot of perspective (have a look at my profile [2], and compare with [1]). In fact, I have actively and successfully pushed for some of "your" issues to be addressed, e.g. Bug 529584 and Bug 558931, I have reported Bug 1000775, and I'm working on Bug 118624, which is a subset of bug 298438. My current WIP patch for Bug 118624, attachment 8411461 [details] [diff] [review], also fixes this bug 369983. And guess what, the first issue raised by other developers in Bug 118624 was PERFORMANCE. What works for your 183 private contacts might fail miserably for business address books having 10,000+ contacts. Which might make this much less trivial than it looks, apart from other issues like localization (sic! per current design), false positives etc. So if you want to see this move forward, I think your best option is to be as encouraging, constructive and cooperative as possible... :) Thanks. [1] https://bugzilla.mozilla.org/user_profile?login=w---ojciech64%40g---mail.com (remove ---) (lots of zeros and only single digits at the time of this comment) [2] https://bugzilla.mozilla.org/user_profile?login=bugzil---la2007%40due---llmann---24.net

(In reply to Thomas D. from comment #12) > (In reply to Szpak from comment #10) > > (In reply to Roman Barczynski from comment #8) > > > Well, it all about config editor. preference name is > > > mail.addr_book.quicksearchquery.format > > please read Bug 298438 discussion - the config that you are giving is > > related to contact sidebar plugin. I also thought it is built in function. > > Never the less if you have this plugin and you set preferences like you said > > it works. > > Hi Szpak, > > I appreciate your continued interest in this matter... > However, the information you provide here isn't correct and might confuse > others, just as your Bug 298438 Comment 17. I dont know what is not correct in my comment 17. > > > mail.addr_book.quicksearchquery.format > This preference is an *inbuilt* part of any default TB installation (no > addons/plugins required) and can be adjusted as correctly described in > comment 8, via Tools > Options > Advanced > General > Config Editor. > > Likewise, there's an *inbuilt* "Contacts Sidebar" which ships with default > TB and does *not* require any addons. From composition window, use View > > Contacts Sidebar (or F9 keyboard shortcut) to toggle visibility of the > inbuilt side bar. I only related to others saying that this is an addon feature. My fault - I did not check this. Please read original bug disscussion - others pointed to me that this prefs are related to addon. > > The pref will change the behaviour for both, > - main AB quicksearch (upper right corner) > - composition's contacts sidebar (left side of composition window). > This works for any version of TB including current TB24 (without addons), to > expand the scope of AB searches or otherwise tweak the default AB search > algorithm. The pref does not (yet) affect recipient autocompletion in > composition's address widget. > > In Bug 298438 Comment 17, you talked about preferences which look like this: > > contactssidebar.search_home;true > All those prefs whose name starts with "contactssidebar" are *not* part of > the default installation; so they must be part of an addon which you > installed. Of course it's possible that that addon ultimately changes or > overlays the inbuilt pref and thus will have the same effect. But no addon > is required to change the AB fields which will be searched. > > > I have more fields added - > > ?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c, > > @V)(Company,c,@V)(Notes,c,@V)(Custom1,c,@V)(Custom2,c,@V)(Custom3,c, > > @V)(Custom4,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName, > > c,@V)(_AimScreenName,c,@V)(SecondEmail,c,@V)(WebPage1,c,@V)(WebPage2,c, > > @V)(WorkAddress,c,@V)(WorkAddress2,c,@V)(HomeAddress,c,@V)(HomeAddress2,c, > > @V)(CellularNumber,c,@V)(WorkPhone,c,@V)(HomePhone,c,@V)) > > > > which I think covers all fields. > > No, that does *not* yet cover *all* fields, e.g. several chat contact fields > are missing. > The full list of fields can be found in my Bug 298438 Comment 20 (as of > 2013-12-08). I related to fields which were available at the time. I think chat tab was not there when we talked about it before. > > (In reply to Szpak from comment #11) > > Read bug Bug 298438 - I also comment on how slow the progress is on this > > issue. > > Szpak, it's certainly true that progress on this issue is slow, more so from > your very limited perspective where this bug and bug 298438 are the only > bugs you ever commented on, according to your profile [1]. Yes I only commented on this one. Though many things I thought about were already added before. But they're just > one single issue out of 10,000+ open bugs and RFE's currently filed against > TB and mailnews core. Pls consider that TB is open source, and it's now > developed and administered almost exclusively by volunteers like me I appraciate your time and effort. > (including some Mozilla developers who sacrifice their spare time), because > Mozilla is no longer actively funding the development of TB (but still > providing the brand, server space, builds, bug management system etc. etc.). > So you're using TB for free, and we're working on it for free, both of which > unfortunately involves an element of "no obligation" as laid out in the > rules for this bug tracker > (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html). Yes but the problem is somewhere else. People just judge software. Its either good or bad. Noone says - oh this software is bad BUT its free so I'm ok with that. Sad reality is that open source compete with paid software and people despite not paying for it expect the same level of funcionality... > > In bug 298438, you were trying to create the impression that I'm slowing > down progress on this bug by asking too many or the wrong kind of questions. > The opposite is true. You think that the opposite is true. I dont. I only talked about your actions regarding this bug. Nothing else. I'm one of the very few people who have been actively, > decidedly, and constantly driving bugs forward for years, and I come with a > lot of perspective (have a look at my profile [2], and compare with [1]). In > fact, I have actively and successfully pushed for some of "your" issues to > be addressed, e.g. Bug 529584 and Bug 558931, I have reported Bug 1000775, > and I'm working on Bug 118624, which is a subset of bug 298438. My current > WIP patch for Bug 118624, attachment 8411461 [details] [diff] [review], also > fixes this bug 369983. And guess what, the first issue raised by other > developers in Bug 118624 was PERFORMANCE. What works for your 183 private > contacts might fail miserably for business address books having 10,000+ > contacts. I know that performance is very important. Search has to be quick. I have never argued against it. You misunderstood me. The point I'm trying to make is - user DOES NOT CARE! You have to make software so its easy to use (in this case - searches everything without customizing) AND WORKS fast. What is a terrible idea (to me) is to say - ok we can not code it so its fast so lets make some strange options and limitations to search. Which might make this much less trivial than it looks, apart from > other issues like localization (sic! per current design), false positives > etc. So if you want to see this move forward, I think your best option is to > be as encouraging, constructive and cooperative as possible... :) Thanks. You have to excuse me but this is the way I think and argue. It is quite decisive and I dont make a lot of room for other opinions unless they are really good :) I'm glad you are tring to push this and thank you again. However I still believe that most of our previous disscusion was a waste of time. > > [1] > https://bugzilla.mozilla.org/user_profile?login=w---ojciech64%40g---mail.com > (remove ---) (lots of zeros and only single digits at the time of this > comment) > [2] > https://bugzilla.mozilla.org/user_profile?login=bugzil---la2007%40due--- > llmann---24.net