After a few days using the "experimental and bleeding edge" email notification, I noticed the following problem: when I receive a Bugsplat notification, I can't tell why I'm on the recipient list. With the previous system: - If my address was in 1st position on the "To" line, I knew I was the Assignee. - If my address was in 2nd position on the "To" line, I knew I was the Reporter. - If my address was on the "CC" line, I knew I was just CC'd. With the new system, I can't tell why I'm spammed. Could you add a line saying "You received this mail because you are the Reporter / the Assignee" or "on the CC list"? Thanks-a-bunch.

One reason you might not want to do this is that it would result in a different message for each user. I personally don't care why I'm receiving a notification. So ... Why not just have a set of fields that always appear in a notification, so it can be customised by the user? I seem to recall this issue being touched upon a few times in the past with the old system, and it makes a lot of sense to me.

A different message per user meaning more server-side work for Bugzilla.

It is the opposite: Bugzilla used to send only one message and that message had 2 names in the "To" line (the Assignee and the Reporter) and several names in the "CC" line. With the new scheme, Bugzilla sends a separate mail to each recipient and I can no longer tell at first sight why I'm receiving the message.

Right. Bugzilla does now send a separately constructed message for each user using the "new" email scheme. I have intentionally left room in the code to allow customized messages per person, I just haven't done any of that work yet.

Cool. I haven't noticed any differences, other than the different senders. I was referring to the body being the same, not the message.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Zach suggested the following reasons you are the reporter of the bug you are the owner of the bug you are watching mpt@mailandnews.com you are listed on the cc-line of the bug you are the qa contact of this bug You are receiving this message because of a unknown reason (just in case something odd happens) Zach forgot: you voted for this bug And I propose [optional: default=no] this is for your records because you made some of these changes. This would really make filtering easier and it shouldn't be too hard to do. -.mozwebtools indicated For filtering you'd be filtering based on the body of a message - generally that's quite an intensive operation and most people (ok, *I* do) prefer to filter based on headers. It'd be nice to have the text there as a visual representation, but a header... um... X-Bugzilla-Reason: qa cc reporter (you're qa, you reported the fault and you're in the cc line) I agree headers are much more useful. Could we move the new or changed status into a header field so there are more characters for the bug summary? wrt watch output X-Bugzilla-Reason: reporter, assignee, qa, cc, voted, changed, unknown, watch[*] suggested syntax for watch: watch[qa:mpt@mailandnews.com]

moving to real milestones...

I've got a horrible feeling without this, when mozilla.org upgrades to 2.14 and old email tech is gone there's going to be lots of complaints about broken filters and we won't even be able to fix them.

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

Is it possible that we can get something that isn't perfect, but works for 2.14?

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

I vote yes, but then I don't know how hard it would be to do. It would be nice if someone could look at this in 2.14 and find out. I suspect, given the e-mail prefs code needs to work this out already, it should be reasonably straight forward.

I'm looking into it... Zach

Rip it apart people ... This will need to be release noted unfortunately ... *sigh* ...

For those who are interested, the header looks like this if all reasons apply: X-Bugzilla-Reason: AssignedTo Reporter QAContact CC Voter Watching isn't supported yet by the email prefs code so it's not supported by this code either. If you received because of an unknown reason the reasons will be blank.

OK, the new version includes the reasons on the body too. It looks like this: You are receiving this mail because: Whoops! I have no idea! or hopefully something more like: You are receiving this mail because: You are the assignee for the bug, or are watching the assignee. You reported the bug, or are watching the reporter. You are the QA contact for the bug, or are watching the QA contact. You are on the CC list for the bug, or are watching someone who is. You are a voter for the bug, or are watching someone who is. Whoops! There is an unknown reason!

Patch checked in r=zach@zachlipton.com, MattyT: you need to relnote the change in the params for existing installs. Zach

Umm... to avoid your feeling of a need to rush, mozilla.org updated to the version that nuked oldemailtech back on June 12th. At the time there were only 7 people still using oldemailtech.

fixed

Bit of a d'oh, but let's not forget there's other installations out there. Anyway, I really wanted to get opinions on the header formatting, is it OK? We can't change it once it's released.

Reopen. I left the %reasonsbody% at the bottom because it is less important than the diffs and many people wouldn't be interested in it. Rather than moving it to the top we should do something to show the end of the comment.

removing patch keyword since this needs more code. :-)

Looks good to me - 7 dashes is how additional comments works. One small nit though, maybe put another blank line between %diffs% and %reasonsbody% on the default param - they look a bit squished given the separation of three lines between diffs and comments. No need for a patch for that one though, whoever checks in can fix it. What I just realised does need to be fixed, is that %reasonsheader% and %reasonsbody% need to be explained on defparams.pl, as all the substitutions need to be explained to the administrator.

Looks good to go to me. And here's some more spam: __.....__ <__ __> | ''''' | |.._____..| | S P A M | |.._____..| | | ''-----''

The description for the param seems to imply that the %reasonsheader% subs parm is going to generate the entire header, when it's really only generating the contents of the header. (It's obvious if you're looking at the default, but not if you're upgrading an existing installation)

*Sigh*. I saw that, but the continual changes wore me down. =) How about you take it, fix it and check it in rather than attaching again.

OK, I fixed it. Hope you like it, because it's checked in now. :-)

Moving to Bugzilla product