7710 - Pref to automatically put me on the CC: list of bugs I change

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, enhancement, P2)

Description

[Sam Allen]

I would like a preference that would automatically put me on the CC: list of
any bug that I ever change. Manually adding myself to each bug is cumbersome;
and also it just increases the amount of spam received by whomever the bug is
assigned to.

Comment 1

[Matthew Tuck [:CodeMachine]]

Bug #7345 addresses the spam issue, and it relevant to this bug.  I'm about to
mark bug #11319 as a dupe of this.  It is specifically about adding to (B)CC
when _commenting_.  You might want the preference to have a couple of choices as
to when to add.

Comment 2

[Matthew Tuck [:CodeMachine]]

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

Comment 3

[Terry Weissman]

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

Comment 4

[Terry Weissman]

[e-mail] 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 .)

Comment 5

[Tara Hernandez]

Chris--there's a bug in bluemartini's database from ronny about this as
well--I'll reassign it to you.

Comment 6

[Matthew Tuck [:CodeMachine]]

I suggest this not occur when you're the QA contact, assignee or reporter,
unless you are set up to not otherwise receive mail in these situations (ie CC
only).

Comment 7

[Chris Yeh]

I read the discussion in Bug #7345. Am in agreement that the value of a BCC 
field makes no sense when the CC field would work just fine. (I really hate 
adding new fields to the database you see.)

When you refer to "preference" are you thinking of a user preference or a 
Bugzilla installation preference?

 

Comment 8

[David Krause]

Chris, I think a BCC field would be useful unless one of the other bugs about
not spamming people with CCs was implemented.  Then a BCC field wouldn't be needed.

I think this should be a user preference and not a bugzilla installation
preference, since there are times when lots of bugs are changed but you don't
want to be cc'ed on them.

Comment 9

[Stephan Niemz]

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.

Comment 10

[Matthew Tuck [:CodeMachine]]

There needs to be three choices here:  Don't, Add Me When I'm Not Already On The
Report, Add Me When I'm Not Already On The CC

I'll move this up to 2.16 due to the number of votes, it may or may not get done
for that.

Comment 11

[Dave Miller [:justdave]]

Taking all of cyeh's Bugzilla bugs.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

Dave: assign this one to me if you are't planning on doing this for 2.16

Comment 13

[Christopher Aillon (sabbatical, not receiving bugmail)]

taking from dave.

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

Moving to new product Bugzilla...

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Since the prefs are getting it's own table, this should depend on bug 73665.  It
is currently targetted to 2.16 and since there is already quite a few bugs that
depend on it getting fixed, I anticipate it will soon.

Comment 16

[Christian Reis]

Folks, I don't really want to the preference, but I could sure use the checkbox
to add. Can I implement this as a partial fix, or another bug? If a checkbox is
allowed, I'd like to place it right under "additional comments":

|                                       |
|                                       |
+---------------------------------------+[ ] Add me to the CC list.

< > Leave as ASSIGNED
< > Resolve bug, changing resolution to [ FIXED     [v]

My justification: when triaging large numbers of bugs, it's VERY tiresome to
scroll to the add cc: list to the right, and then down again. I forget it many
times, and have to re-spam. Finally, it seems like grouping things we use
commonly together (reassigning, adding CC, commenting. - even attaching is
closer than adding CC and it's way more uncommon) 

Please comment, I have a patch in hand.

Comment 17

[Christian Reis]

Damn, why did that happen? I mean _under_ the comment box of course.

|                                       |
|                                       |
+---------------------------------------+
[ ] Add me to the CC list.

< > Leave as ASSIGNED
< > Resolve bug, changing resolution to [ FIXED     [v]

Comment 18

[Matthew Cline]

Putting the "add me to CC" button under the comments box sounds like a great
idea to me.

Comment 19

[Diego Biurrun]

I would like to have the preference available but I would also like to see the
checkbox approach so that people can choose which way they prefer.

I think the checkbox should be below the CC box to have all CC stuff grouped
logically.

Comment 20

[Christopher Aillon (sabbatical, not receiving bugmail)]

This bug is not having a checkbox underneath the comments.  It is about a
backend pref to automatically do it without having to check anything on or off.
 Changing summary to better reflect the intent of this bug.  The checkbox thing
should be a separate bug.

Comment 21

[Christopher Aillon (sabbatical, not receiving bugmail)]

Some thoughts on how I plan to implement this once the emailprefs table has been
created. This all assumes that you have the pref turned on, of course.

When viewing a bug, the "Add CC" input field will have your e-mail address
already there.  However, if you have JavaScript enabled and you are the assignee
or QA contact or already on the CC list your name won't be in the CC list.  This
way there is a visual notice to the user that this feature is turned on.  It
also provides users a way of selectively foregoing adding themselves to CC on
certain bugs if they so choose.

If JavaScript is not turned on, no problem.  Once the bug changes have been
submitted, the perl backend will also check to see that they are not the asignee
or the QA contact, and I believe the code already checks to see that they are
not already on the CC list.

Any feedback on my thoughts for implementing this are appreciated.

Comment 22

[Christian Reis]

> When viewing a bug, the "Add CC" input field will have your e-mail
> address already there.  However, if you have JavaScript enabled and you

This is great. Either that, or add automatically to the CC list after
the bug is sumbitted. If my UI gets accepted for bug 34488, then you
could simply check the box automatically every reload. A much better
solution IMHO (specially since the current Add CC: sucks).

> are the assigneee or QA contact or already on the CC list your name
> won't be in the CC list.  Thi s way there is a visual notice to the user

Huh?  I trust you meant "you won't be in the Add to CC: input box"
right? You're not going to remove me from the selectbox are you?

And why Javascript? This is easily done in perl.

> that this feature is turned on.  It also provides users a way of
> selectively foregoing adding themselves to CC on certain bugs if they so
> choose.

Sounds good to me. Though I think using my checkbutton is a better idea.

Comment 23

[Jacob Steenhagen]

> once the emailprefs table has been created

Bear in mind that my current schema for the emailprefs table (bug 73665) is
heavily based on making it a table for e-mail filtering prefs, not general prefs
(there will be a column for each filtering category). Of course, any design that
makes the table more robust (ie, able to be used for general prefs) without
degrading what I'd like to be able to do with it for e-mail prefs (basically,
combine the existing 'watches' table with this new filtering table to obtain
much more robust robust watching and filtering capabilites (ie, being able to
watch specific keywords/componets/people and having different filtering prefs
for each).

Comment 24

[Christopher Aillon (sabbatical, not receiving bugmail)]

Originally, justdave and I had discussed the email prefs table being used for
other prefs, this included.  That is not the case anymore, and a general user
prefs table will be needed instead.  I filed bug 98123 for the userprefs and am
switching the dependency to that bug instead.

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

->2.18

Comment 26

[Dave Miller [:justdave]]

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

Comment 27

[Boris 'pi' Piwinger]

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

Comment 28

[Christopher Aillon (sabbatical, not receiving bugmail)]

Sigh.  No time to work on this anymore...  ->Default owner.

Comment 29

[Bradley Baetz (:bbaetz)]

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

Comment 30

[thebeastwitheyesthatstared]

what is the current status on this?

Comment 31

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 32

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 33

[Olav Vitters]

Attachment: Patch v1 against Bugzilla HEAD 29 March 2005

Adds a pref to control the state of the addselfcc ('Add [e-mail] to CC
list') checkbox. For me changing means either commenting or changing some
field. Even if I only comment on a bug I still want to CC myself. In the rare
case that I do not want to, the patch allows the checkbox to be deselected.

Patch adds user preference 'state_addselfcc' (run checksetup.pl) with
description "Automatically put on the CC list of every bug changed or commented
upon". The name of the preference + decription maybe need improving.

I didn't know how to keep the setting-descs.none.tmpl within 80 characters.. it
was already 84 characters, now 117 (oops).

reviewer: Please only assign to me if you agree the bug can be fixed this way.

Comment 34

[Olav Vitters]

Attachment: Patch v1 against Bugzilla HEAD 30 March 2005

Same patch but updated for latest checksetup.pl

Comment 35

[Joel Peshkin]

Comment on attachment 178955 [details] [diff] [review]
Patch v1 against Bugzilla HEAD 29 March 2005

This would need some code to actually act on the change.  And... it should
probably not add me to the cclist if the only change I am making is to remove
myself from the CC list.

Comment 36

[Joel Peshkin]

Comment on attachment 179090 [details] [diff] [review]
Patch v1 against Bugzilla HEAD 30 March 2005

ditto

Comment 37

[Olav Vitters]

(In reply to comment #35)
> (From update of attachment 178955 [details] [diff] [review])
> This would need some code to actually act on the change.  And... it should
> probably not add me to the cclist if the only change I am making is to remove
> myself from the CC list.

The setting controls the 'Add [e-mail] to CC list' checkbox. That
checkbox will be hidden when you are already on the CC list. I thought this bug
was only meant to control that checkbox because this bug depends on that one
(bug 34488).

Using the existing checkbox would mean that even just clicking Commit would CC
yourself. This is not like the description (wants some change).

Even when the setting is on, I'd still like to be able to disable it if I want
it while submitting (going to prefs for one bugreport isn't nice). I'd need a
checkbox for this, but having two checkboxes seems confusing to me.

I believe re-using the existing checkbox is the nicest way to fix this, while
still allowing it to be easily overridden while committing. Strictly following
the description of this bug doesn't make sense to me.

Suggestions for a nice way to fix this welcome (how to deal with the existing
checkbox + way to override it)

Comment 38

[Tuukka Tolvanen (sp3000)]

(In reply to comment #37)
> Suggestions for a nice way to fix this welcome (how to deal with the existing
> checkbox + way to override it)

Fix what? What you described sounds completely correct to me.

...I suppose the patch could use re-review, then? Joel?

Comment 39

[Olav Vitters]

Attachment: Patch v3: Bugzilla HEAD 2006-05-01

Now has three states:
 - Always add me to the CC list
 - Do not automatically add me to the CC list
 - Do not add me if I have a role on this bug

This patch only changes checksetup.pl and templates because all the hard work is already done by the 'add me to the cc-list' checkbox. This checkbox will not show when the user is already on the cc-list, so the patch doesn't need to implement that.

Tested by changing the state_addselfcc userpref, enabling/disabling useqacontact and trying various combinations for assigned_to/reporter/qa_contact (via SQL).

Comment 40

[Olav Vitters]

Attachment: Patch v4: CVS 2006-05-07, add has_role

<LpSolit> bkor: moreover, I think you should write [% has_role = .... %] and then write [% " checked = \"checked\"" IF (always or !has_role && unless_cc) %]

This version has has_role.

Comment 41

[Olav Vitters]

Attachment: Patch v5: Change description, change layout IF statements

Fix review from IRC

<LpSolit> bkor: I think you should change the descriptions of your param in user prefs
<LpSolit> maybe: "Automatically add me to the CC list of bugs I change : always / never / only if I have no role on them"

done

<LpSolit> bkor: write...
<LpSolit> foo
<LpSolit>   || bar
<LpSolit>   || baz
<LpSolit> same for IF (user.settings.state_addselfcc.value == 'always_cc' || !has_role
<LpSolit>    && user.settings.state_addselfcc.value == 'cc_unless_role')  %]>
<LpSolit> IF foo
<LpSolit>   || (bar && baz == bazz)

done

<LpSolit> I'm surprised that bug.qa_contact.id works even when bug.qa_contact is undefined
<bkor> I assumed it would be 0 in those cases (I did test with qa_contact being null)
<LpSolit> no it's not
[..]
<bkor> should I put a  && bug.qa_contact  or maybe  && bug.qa_contact.defined  in there (just to avoid possible problems in future)?
<LpSolit> yeah, && bug.qa_contact would be fine

done

+ also forgot "," at end of line in setting-descs.none.tmpl for always_cc + cc_unless_role (why did that work?!?)

Comment 42

[Olav Vitters]

Attachment: Patch v6: Brown paper bag release

s/always_cc/always/

Comment 43

[Frédéric Buclin]

Comment on attachment 221242 [details] [diff] [review]
Patch v6: Brown paper bag release

Works fine. r=LpSolit

Comment 44

[Frédéric Buclin]

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.477; previous revision: 1.476
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--  edit.html.tmpl
new revision: 1.75; previous revision: 1.74
done
Checking in template/en/default/global/setting-descs.none.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/setting-descs.none.tmpl,v  <--  setting-descs.none.tmpl
new revision: 1.8; previous revision: 1.7
done

Comment 45

[Max Kanat-Alexander]

Relnoted as part of bug 349423.