256075 - field for CC'ing only this change

Status: NEW

(Bugzilla :: Email Notifications, enhancement, P4)

Description

[Asa Dotzler [:asa]]

There are many times when I want to notify someone with my Bugzilla change, but
they don't need to be permanently added to the Cc: list for that bug. I also
have lots of people adding me to the Cc: list just to make sure I see one
particular comment or change and cleaning up all the bugs where I'm Cc:'d but
don't need to be is a time consuming task. 

If there was a field that said "Cc: for only this change" that would make me and
lots of other users happy.

Comment 1

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 3

[Mark Côté [:mcote]]

I know this is a really old bug, but now that we have needinfo, is that sufficient for your requirement here?

Comment 4

[Kent Rogers [:mrbball]]

This wasn't my bug, but it is a feature that has been requested at my installation
and I'd like to see it implemented.  This functionality existed in our previous bug
tracker and was quite useful.

needinfo implies (actually explicitly states) it is a request for more information.
This RFE is obviously totally different.  I don't know how the needinfo mechanics
actually work, but IMO trying to use it for the purposes of a one-time CC would be
very confusing at best.

Comment 5

[Asa Dotzler [:asa]]

Need info only covers some of the use cases. I think this is still a useful feature request. If not, feel free to resolve as wontfix.

Comment 6

[Kent Rogers [:mrbball]]

Attachment: patch_for_256075.v1

I've been wanting this feature for a while and finally decided to implement
it.  It wasn't too complicated.  Since it's not really a field, it didn't
require a lot of overhead.

The patch was made in master on top of commit f4c8d62.

A few notes:
- Users being one time cc'd are checked before a bug is updated
- Bug visibility restrictions are honored (i.e. users do not receive email if
  the bug is not visible to them)
- The "Ignore Bug Mail" setting is honored (i.e. email is not sent)
- Watching someone who is one time cc'd is honored
- The one time CC "field" is available in both single & multi-bug updates
- There is no preference for disabling it in general since it is assumed that
  the bug updater had a very specific reason for cc'ing a user on a
  particular change.

There is probably some detail (or many) I have forgotten, so comments are
welcome.

BTW, I tried to ask for this bug to be assigned to me by clicking the link
in the bug (mailto:[e-mail]), but it did not work.

Comment 7

[:glob ✱]

instead of adding another control to the UI, i suspect we may be better served to wait for bug 218917 to land, and then support "mentions" in comments .. eg. any comment with @glob would email me a notification.  this is much more inline with other sites, and doesn't add anything to the ui.

thoughts?

Comment 8

[Kent Rogers [:mrbball]]

Well, I can think of multiple reasons why that isn't ideal.  It's unlikely that you would
normally mention someone's name in the comment, so you would have to add extra text.  Also,
the auto-completion feature of the control I added would not be available.  I understand
real-estate concerns.  I don't think the CC List area of the page is overly crowded but if
it would help, I could hide this control inside the CC List 'Edit' area.

I see that bug 634947 is for the feature you reference and is dependent on bug 218917.  I'm
not sure, but this might be the first time I've seen either of those bugs.  As an aside,
the implementation of 218917 will cause problems for my non-public installation, where
I've already made changes such that username != email. :-(

Anyway, I think both features are useful, but if you decide that the one time CC feature
is not desirable or the @username feature is a reasonable replacement, it would be best to
close this bug as WONTFIX.  In general, I would say the same for any bug where a fix will
not be accepted/implemented, as doing so may save someone some time. :-)

Comment 9

[Frédéric Buclin]

Not marking this bug as wontfix for now, but I first want to see how bug 634947 will be implemented as both bugs will probably share the same backend code. Also, bug 218917 is big enough that it should land first.

Comment 10

[Frédéric Buclin]

Comment on attachment 8617342 [details] [diff] [review]
patch_for_256075.v1

Waiting for the blocker bug to be fixed first, to avoid conflicts.