Add a search choice called "All Addresses" to encompass Bcc and all address possiblities in one test. Rational - one of the most frequent things I do is search mail for everything I sent or received from an individual - an address which is not fixed, so saved searches is not a solution. seach currently has choices for To, To or Cc, From - but it is missing Bcc, and it is also time consuming to make the 2 term search of "To or CC="xxx" OR From="xxx". For such a simple and common search function there would be one term to cover all address types.

surprised this isn't in more demand. Perhaps it's more enterprise related? nominating wanted-thunderbird3

The combined From, To, and CC is not hard to implement. It's really an issue of cluttering the filter definition screen with options that are not really necessary. Note I am already in the process of adding two additional search terms (junkpercent and junkstatusorigin) so clutter is an issue. As for BCC, the problem there is that it does not make sense for received mail. Most casual users don't understand that blind CC really means blind. Adding it to a filter search might contribute to that confusion, or worse convince someone that the search proves a particular email was not received by someone, when in fact you cannot prove that.

your point about received mail is a given. I don't understand the last phrase. And I'm not sure where you get "not necessary." As for people who might not understand bcc, why should that impact MY usability? If their lack of understanding is the issue, then we change wording, but don't avoid adding the functionality.

By "not necessary" I mean that the function is available, but it just takes more steps to define it (that is, two filter steps instead of one.) In contrast, the BCC search is not available at all at the moment. I can see the value of a BCC search for sent messages. Would you be happy, as a start, to see just the BCC implemented? If you want me to clarify some statement, you'll need to be more specific than "I don't understand the last phrase" like what phrase exactly, for example.

(In reply to comment #4) > By "not necessary" I mean that the function is available, but it just takes > more steps to define it (that is, two filter steps instead of one.) In > contrast, the BCC search is not available at all at the moment. I can see the > value of a BCC search for sent messages. Would you be happy, as a start, to see > just the BCC implemented? *All* is required, in one step, or the results are not accurate - and accuracy is the goal here. > If you want me to clarify some statement, you'll need to be more specific than > "I don't understand the last phrase" like what phrase exactly, for example. Sorry. Last phrase of last sentence ends after comma, "or worse convince someone that the search proves a particular email was not received by someone, when in fact you cannot prove that." changing wanted-thunderbird3? to blocking-thunderbird3? (what good is archived mail if you can't leverage the contents accurately?)

(In reply to comment #5) > > *All* is required, in one step, or the results are not accurate - and accuracy > is the goal here. > Why can't you just define a single filter with multiple search terms? That achieves the same goal and accuracy doesn't it? > > Sorry. Last phrase of last sentence ends after comma, "or worse convince > someone that the search proves a particular email was not received by someone, > when in fact you cannot prove that." > Well suppose I'm concerned that person X is receiving emails on a subject. So I search for that subject, as well as your new ALL field. When there is no match (including no BCC match) I convince myself they did not get the email - when in fact BCC search does not really work for received emails.

(In reply to comment #6) > (In reply to comment #5) > > > > *All* is required, in one step, or the results are not accurate - and accuracy > > is the goal here. > > > Why can't you just define a single filter with multiple search terms? That > achieves the same goal and accuracy doesn't it? Filters (and views and saved searches as mentioned in comment 0) don't scale - hence this enhancement request. Please tell me how to do what you suggest for 1,240 contacts. Or, more realistically, the 100+ people with whom I correspond on a regular basis - which of course changes over time. Theses methods suffer the similar issues as current quick search - Bcc is not a supplied search target and you must do multiple (3) search terms to get to/from/cc/bcc - only it's worse because the search is now static. Now multiple that by 100. I should simply be able to type in someone@somewhere.com and see all correspondence to+from that person. I'd like to suggest this discussion be about how to implement the requested functionality.

Based on the BCC implementation strategy discussed at http://mxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgSend.cpp#4620 it sounds like it is just a normal header, but only added to messages stored in the Sent folder. I'm guessing therefore that the implementation will be fairly straightforward (at least for me, since I've done some other hacking on the search terms recently). What concerns me is the lack of discussion on this issue. I have never quite figured out an effective way to get mailnews owners and peers to discuss issues like this, other than to do the work and submit a patch for review. So for that reason I have avoided possibly controversial issues, leaving that for those that seem to be better connected than I am. And BCC is a controversial issue, I've had clients that ban all uses of BCC for example. It's also important from a security perspective. So I'm willing to add this to my list of things to do, and you are slowly convincing me of its importance. But can you get some of the mail or mailnews peers and owners to comment here that they would be willing to accept such a patch before I do the work? Clark, you are now cc's here I see. Are you willing to see this added as a search term to the existing interface?

(In reply to comment #8) > Based on the BCC implementation strategy discussed at > http://mxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgSend.cpp#4620 > it sounds like it is just a normal header, but only added to messages stored in > the Sent folder. which can of course these days be *any* folder, because of manual copies, automated copies via filters, and compose-related UI where user specifies the target (in my case, Inbox) > What concerns me is the lack of discussion on this issue. I have never quite > figured out an effective way to get mailnews owners and peers to discuss issues > like this, other than to do the work and submit a patch for review. Good point other comments would be good. Devs often don't comment until asked by CC or by review. Hopefully Bryan whom I cced will add insight - perhaps even say this bug is obsolete given his ideas for improving search. And I've added dmose and Wayne.Woods from bug 372068, where related discussion has occurred and he put up some screen shots. > So for that > reason I have avoided possibly controversial issues, leaving that for those > that seem to be better connected than I am. And BCC is a controversial issue, > I've had clients that ban all uses of BCC for example. It's also important from > a security perspective. So I'm willing to add this to my list of things to do, > and you are slowly convincing me of its importance. But can you get some of the > mail or mailnews peers and owners to comment here that they would be willing to > accept such a patch before I do the work? Sometimes controversy drives innovation :) Bcc receives little attention I think because is it seen as cluttering UI (which I think is short sighted because adding function need not clutter UI) plus most people don't use Bcc, ever, (further reinforcing the former point) including, importantly, devs. (hmm, lots of commas) But Bcc has several good uses. For example: * to prevent people from replying to an entire group when the desired response format is all responses go to author ("reply all" has it's faults) * to avoid subjecting recipients - who have no need of knowing each other or already know who the others are - to spam either through intentional harvesting or unintentional harvesting due to malicious software on a receiver's PC; this sending strategy dates to the earliest days of spam * distribution of confidential information * (as I'm thinking about this) I know some people Bcc themselves on all their sent mail, so we should examine whether doing any Bcc bug creates problems for this class of user. * bcc Newsgroup postings as a heads up to the person to whose post you are replying (or someone else) Bryan is working on great search enhancements but time frame is unknown, so perhaps this bug (if details are worked out) might still be useful on trunk as a test and proof a concept for both UI and functionality. FWIW, we have other Bcc enhancement requests - http://tinyurl.com/5qxbd9 // and subset of those with votes = http://tinyurl.com/4mo482 - although some are a bit odd.

Isn't it possible to set up a custom header BCC and use that as a workaround? (Apart from some current bugs with custom headers matching after the fact.) Though if we add a "All" (or should that be "Any") address criteria the BCC could at least be included there without any confusion.

yup to both. suffered with the former for some time :)

This sounds like something ideally suited to the global database stuff that andrew is working on.

Wouldn't block, but placing in the wanted+ bucket.

xref/dupe bug 161338

(In reply to comment #14) > xref/dupe bug 161338 and bug 420463 Bug 213318

I see now what is difficult about this bug. The IMAP search code that generates the IMAP string is very ancient, and uses handcoded manipulation of character strings. This bug will require many search terms at once, for which there is no direct support in the code. Also, there is no support for BCC in the nsIMsgDBHdr. So I think what I will do is trickle in separate patches. I'll do a starter patch that just adds a new search term "All Addresses" which to start will just combine the current ToOrCC with From, and just do it locally. That will at least get the "All Addresses" string.

As the first of what will probably be three patches for this bug, add To, From, and CC for local search only as "All Addresses". This also adds what will probably be the only string for this bug. Still to come: 2) Add support for BCC to nsIMsgDBHdr and the local search 3) Support offline IMAP

"Any address", or "Any address field"? "All addresses" can't match...

davida in comment #12 > This sounds like something ideally suited to the global database stuff that > andrew is working on. indeed, needed in gloda in addition to the existing UI

Or "Some address", "An address" perhaps.

I don't have a strong opinion about the wording, but of the options presented I prefer "Any Address". I would appreciate another opinion or two before I change this.

referring only what is presented in the UI, "All" seems stronger, and potentially clearer to a user (although the backend is doing OR == any). "Search any" sounds random". Depends on perspective I suppose... find in any field search all fields ...

Comment on attachment 359225 [details] [diff] [review] To, From, and CC for local search In general this is looking good, though I won't be able to test this until Monday. >diff --git a/mail/locales/en-US/chrome/messenger/search-attributes.properties b/mail/locales/en-US/chrome/messenger/search-attributes.properties >-4=Priority >-5=Status >+4=Status >+5=All Addresses ... >-43=reserved for AB >+43=Priority I don't quite understand why you are doing this. Is it so you can group All Addresses with To and Cc? From an l10n update perspective, this file is a nightmare (though not your fault). To reduce their pain as much as possible, I think we should leave priority and status as 4 and 5 respectively, change 43 to All Addresses, and then we'll post to the l10n newsgroup when we land the patch. I probably also need to get round to filing a bug on improving this situation (generally) as well. Also, I haven't seen Bryan's input on this bug, so additionally requesting ui-review to get his thoughts on the "All Addresses" string.

(In reply to comment #23) >I don't quite understand why you are doing this. Is it so you can group All >Addresses with To and Cc? Exactly. If you don't do this, then the "All Addresses" appears by itself near the bottom of the list, which seems strange, and maybe makes you wonder if it is similar to From, ToAndCC, and the other address fields. I also moved the All Addresses into a prominant position, as I think it will be the most commonly used address type. So I really think it needs to be moved. I tried to make the change as simple as possible, by only moving a single unrelated (and relatively less important) term to the bottom. Byran, please also comment on the importance of grouping these terms together, as I think it is important.

from a usability POV it looks like the right thing to do.

In other areas I've started to using the text: "Involves (from,to,cc,bcc)", though I haven't tried to land this anywhere. Even though being specific on the from,to,cc,bcc appears as though we're letting programming semantics leak through we present those same semantics in the composer so I think it's not too foreign a concept. Other combinations might work as well, I don't have a real strong feeling here.

"From, To, CC or BCC" would match the existing semantics - though this patch does not actually include BCC. So the correct short-term wording might be "From, To or CC". Any thoughts on whether I should change this to be correct for this partial fix, or assume that we will add the BCC eventually and add it in the string now? I don't really understand how annoying it would be to localizers for this string to be new with beta 2 ("From, To or CC") and then change again before beta 3. The advantage of "All Addresses" is that it is vague enough to work for both cases. Also Bryan we need your input on the importance of grouping all of the address fields together in the drop-down search list, as mentioned in comment 23 and comment 24.

(In reply to comment #23) >>diff --git a/mail/locales/en-US/chrome/messenger/search-attributes.properties >>b/mail/locales/en-US/chrome/messenger/search-attributes.properties >> >>-4=Priority >>-5=Status >>+4=Status >>+5=All Addresses >>... >>-43=reserved for AB >>+43=Priority > > I don't quite understand why you are doing this. Is it so you can group All > Addresses with To and Cc? > > From an l10n update perspective, this file is a nightmare (though not your > fault). To reduce their pain as much as possible, I think we should leave > priority and status as 4 and 5 respectively, change 43 to All Addresses, and > then we'll post to the l10n newsgroup when we land the patch. Mark is right. This is *really* bad from an l10n perspective and alone for that reason the review should be denied. Please change the patch per Mark's suggestion.

Given the l10n issues here, and the fact we'd like to have these options grouped together, I think we need to do something slight different (and it may need to be covered in a separate bug. I think we should provide a mapping of the internal nsMsgSearchAttrib value to the UI value. We already have a map in nsMsgSearchTerm.cpp for saving though that includes spaces (which is a bit of a shame as we can't really re-use it). However I think mapping ids to strings for picking up the l10n string would give us a bit of bonus - l10n devs will be able to know what the strings actually refer to in English, and we'll be able to sort them in whatever order we wish. I haven't looked too much into how complicated this would be to implement, but I would hope it can be done fairly simply.

Based on the comments, I added the new search term to the first empty position, making it out of order. I propose then that we accept this patch, and add the reordering as a follow-on (along with the two existing planned follow-ons.) I also left "All Addresses" as the string, since there was not a solid consensus to change it (and I can add BCC without changing that string.) Is this what you had in mind?

(In reply to comment #27) > "From, To, CC or BCC" would match the existing semantics - though this patch > does not actually include BCC. So the correct short-term wording might be > "From, To or CC". Any thoughts on whether I should change this to be correct > for this partial fix, or assume that we will add the BCC eventually and add it > in the string now? I wouldn't add the string in now, before we actually land the functionality. That could end up being more confusing for people who see it. > I don't really understand how annoying it would be to > localizers for this string to be new with beta 2 ("From, To or CC") and then > change again before beta 3. I have no idea here either, but likely it's the right thing to do. > The advantage of "All Addresses" is that it is > vague enough to work for both cases. That might help for l10n, but I don't think it really helps people in the long run. I would recommend the real, less vague string. > Also Bryan we need your input on the importance of grouping all of the address > fields together in the drop-down search list, as mentioned in comment 23 and > comment 24. I think we need to group those items together, placing the "All" item down at the bottom will convey some kind of meaning that it's different than the other to, cc items; something that isn't true.

(In reply to comment #31) >I wouldn't add the string in now, before we actually land the functionality. I don't understand this comment. The proposal here is to land the string "From, To, or CC" which will match the new internal "AllAddresses" search term, along with the functionality to implement it on local search. If we do that, then the string will match the implemented functionality for beta2. For beta3, hopefully the BCC functionality will land, and the string will be changed to "From, To, CC, or BCC". Any beta2 testers will see that the string that describes any filter implemented with the "AllAddresses" internal term has changed, and the filter will now also search BCC. I'm beginning to believe that trying to get this partial implementation to span betas is more effort than it is worth. Maybe we should just delay this initial landing until post-beta2, and try to get the full set of patches into beta3. I'm neutral on this - the patch is community service to me, not critical to my other work. Any opinions one way or the other could persuade me.

Comment on attachment 360061 [details] [diff] [review] "All Addresses" moved to new spot, now out of order I'm hoping the (my) confusion has cleared here so I'll be as specific as possible. ui-review+ for landing the string "From, To, or CC" which matches the new internal "AllAddresses" search term. But please make the sort order such that "From, To, or CC" is directly below the other "To", "CC", "To or CC" search terms and not at the bottom of the list.

I changed the string to the one requested by Brian. I am suggesting that we land as is, and fix ordering (which is significant new code) in a follow-on patch. Also, need to add BCC in a follow-on patch.

Comment on attachment 363082 [details] [diff] [review] [checked in] String is now From, To or CC >diff --git a/mail/base/content/mailWidgets.xml b/mail/base/content/mailWidgets.xml >--- a/mail/base/content/mailWidgets.xml >+++ b/mail/base/content/mailWidgets.xml >@@ -1110,10 +1110,11 @@ > this.setAttribute("selectedIndex", "5"); > } > >- // if it's not sender, to, cc, or toorcc, we don't care >+ // if it's not sender, to, cc, alladdresses, or toorcc, we don't care nit: I think you should use AllAddresses and ToOrCC here. Also can you make it "If ... care." so that its a proper sentence. Ditto in suite's version. >+ case nsMsgSearchAttrib::AllAddresses: >+ { >+ PRBool boolKeepGoing; >+ aTerm->GetMatchAllBeforeDeciding(&boolKeepGoing); >+ msgToMatch->GetRecipients(getter_Copies(recipients)); >+ err = aTerm->MatchRfc822String (recipients.get(), charset, charsetOverride, &result); nit: no space before ( please - 3 places in this section. r=me with those fixed.

Comment on attachment 363082 [details] [diff] [review] [checked in] String is now From, To or CC Checked in: http://hg.mozilla.org/comm-central/rev/6bdc9d138c65

The remaining work to do on this bug is in bug 488577. Rather than keep this bug open, let me close this and just do anything remaining there.