Closed Bug 7345 Opened 25 years ago Closed 24 years ago

Add a BCC capability to bugzilla.

Categories

(Bugzilla :: Bugzilla-General, enhancement, P3)

enhancement

Tracking

()

VERIFIED WONTFIX

People

(Reporter: CodeMachine, Assigned: justdave)

References

Details

It would be nice to have a BCC capability that allowed you to receive updates on
a bug while not being in the CC list.  The logic for this is two-fold.

(a) Some people prefer to lurk, and then they will help when they think they
can.  If they can't lurk, they can't help.  A BCC that's not shown on the
Bugzilla pages would give them some sort of privacy.
(b) Interested observers shouldn't really be on the CC list, since they aren't
involved in fixing the bug as such.  Theoretically lots of people might be
interested in the progress of the bug, but they are hardly going to change the
CC list since they are not involved.
(c) It looks to me like anyone can remove you from the CC list.  I wouldn't want
other people to be able to do this for me.

The suggested interface would be a simple "Notify Me Of Changes" button.
Funny...  I've never had a problem with adding myself to the CC line of a bug
I'm interested in following...  In fact, I just did so with this bug (I hope you
don't mind).  I think it's pretty clear that you don't have to be DOING
something to take an interest in the activity that goes on...  Therefore, I
don't really think a BCC feature is necessary.  A "Notify me of Changes" button
might be faster to use than the CC field, but even there, there is one small
problem with this idea: sometimes it is handy to add someone besides yourself to
the CC line.  For example, if you found a layout bug, and you wanted to notify
someone expert on the layout code of the bug, then as it stands now, all you
need to do is add them to the CC line.
I'm not advocating the removal of the CC facility, but as it stands, it will not
scale to a large number of interested people, as there probably will be once
Mozilla is released.

Correct me if I'm wrong, as I haven't used the CC before, but as I see it, if
there were a large number of people, you could easily accidentally remove
someone else.  Not to mention that all those names wouldn't fit in there
anyway.  I've noticed you don't have a problem with CCs, but what about if there
were 50 of you?

I'd probably classify myself as a semi-lurker, and everyone lurks to different
degrees.  A lot of people prefer to lurk.

As for adding someone else to a bug, you could certainly allow this as well.
With this you could even provide some sort of security like with mailing lists
to avoid abuses of the system like subscribing someone who didn't ask for it.

Actually, the logic was three-fold.  =)
Also, it appears that just changing the cc notifies everyone.  This would be
another advantage of bcc.
Hmm...  I don't know about lurkers...  I guess it's hard for me to think about
this since I am not one. :-)  But I guess a BCC line would be nice for them.
Anybody else have any thoughts on this?  I think if it would lead to more
involvement, this would be cool!!

On the CC thing: I think you are probably correct that it is easy to remove
someone, and that if 50+ people put themselves there, it would run out of space
(I'm not really sure what the space limit is here).  I've wondered about this
before, too.  I guess, granted, the solution would be to replace the text-entry
field with a kind of "mailing-list" type management system, along with a "Notify
Me Of Changes" button as you propose (if you do this however, you'll also need a
"Delete me from the List" button, too).  This would certainly solve the current
limitations of the CC field.

The only thing I worry about with this approach however is that implementing
such a mailing list-type arrangement would involve much more complex code than
the simple free-form CC text field does at the moment...  I guess what I'm
asking is, is this kind of development effort worth it for the benefits it would
provide?  And even then, would it even really SOLVE anything??  Or would it just
encourage hacking??  I mean, yes the current system possibly leaves a security
hole, but if you want to go down that route, I can also point out many other
security holes in Bugzilla, too.  I don't know if I want to see Bugzilla become
security-conscious to the point of paranoia like this unless absolutely
necessary...  If you really start fixing all the security holes in Bugzilla
(e.g. possibility of anyone spamming it with tons of superfluous bugs,
overloading the database with oversized attachments, deleting bugs at will,
trashing bugs, etc.), then I think Bugzilla would virtually become useless to
practically any outsider...  At that point, you might as well make it only open
to Netscape folks.  Such a system as Bugzilla **MUST** be open to an extent if
it is to work properly and efficiently.  The only *real* way to ensure that it
works smoothly is to make sure people are using it in a responsible way.  That's
the only reason I worry about things like this...  Once you start going down
that route of worrying about every little security hole, it is hard to decide
just when to stop.
I don't think any bcc facility would be be much more complex.  All it would be
would be a hidden field, that a user would be added to and removed from.  There
probably should be some sort of display as to whether you're on the bcc list.

What you're saying about security holes is certainly true, but this can probably
be plugged without making it much harder for users.  Have you needed to put
someone else on a cc before?  Maybe, but I'd figure you don't do it that much.
It would be a very small issue for the userto confirm this.  But anyway, this is
only a small issue in the RFE - the existence of the BCC is the most important
thing.

I think you might only be able to add bugzilla account addresses to the cc
anyway, so it's less of a problem.
I think I would agree that the real answer is to make it so one can only add
Bugzilla account addresses to the cc field (if it isn't this way already).  I
still don't think a user confirm feature would be worth the trouble.  My
reasoning is that although I haven't had to do it much, I can imagine that for
people like the Netscape developers, who might need to do this very often, it
might get to be a nuisance having to do this every single time.
OK, perhaps this needs to be separated into the component issues.

(1) Controlling adding and removing users.

Perhaps you could set up which users can add and remove you in your user
preferences.  But I would suggest you would normally be the only one who should
be able to remove you.  Allowing others to add you is still probably okay.

(2) Ability to monitor a bug confidentially, and not spam everyone with CC list
changes.


The way I feel this should be implemented is as follows:

Firstly, maintain a current user status.  This would be "Uninvolved", "Involved"
and "Monitoring".  The last two statuses would be sent notifications, and the
middle would be extracted to an read-only "Involved" list that would take the
place of the current CC list.  If this list changed, notifications would be sent
out.  Hence, people merely changing their status to monitoring won't end up
spamming notifications to everyone else monitoring the bug.

I think it's clear that not only might users want to lurk yet still monitor, if
they're not involved in fixing the bug, there's no real reason they should be
forced to clutter the CC field with their name just to monitor it.

You could also add and remove other users through text fields like the CC now,
but they would be relative ie changes from the status quo, rather than absolute,
like the cc list.  The only thing that concerns me about the previous bit is
that it might clutter the main screen, and I'm not sure whether it's rare enough
to want to move it to a button you need to press.

In a way this is similar to the current comment system, with an addition
mechanism (Additional Comments) and a read-only field (Description).  Would you
trust someone to keep your comments intact if it was all one big field?  Not
necessarily maliciously, but the possibly of accidental changes is there.
A quick thought:  removing users from the involved list should be ok as long as
they still monitored the bug.
Also "List Bugs I'm Monitoring" (ie monitoring/involved in) and "List Bugs I'm
Involved In" would very useful as "quick queries" from the initial menu.
Funny--I think I've seen this idea come up before.  To that I say: I believe it
is already possible to see what bugs you are involved in, etc.  Just open the
query page and enter your e-mail address in the field, and click the "cc" or
"reporter" radio buttons.

All the same, this issue has come up before.  In the past I've always commented
that this might simply lead to more bloat, especially since it really boils down
to providing another redundant method of doing what you can already do with the
query page.  But now I am wondering if you haven't come up with the perfect
solution by having a list of "quick queries" one could run.  I am assuming of
course that by this you mean a list of common queries with pre-defined values
for the query page, right?
Yes, I think this would be a good solution, although it still would be nice for
new users to get these queries I talked about.  At the moment, the saved queries
seem to be stored in the cookies file rather than server-side, so if you use a
browser on two computers you're out of luck.  =(

Anyway, I might put in an RFE for this.

Do you know where previous discussion/bug report on the original idea might have
been?
See bug #8650 and bug #5672 for those interested in this side issue.
Just thought I'd post my take on the cookie issue: Many people seem to have
complained in the past about Bugzilla's use of cookies.  Is this really such a
problem?  Obviously, I don't think so; privacy/security concerns about the
general use of cookies aside for a second, I don't think storing all these
preferences on the server side is a very good idea.  In the first place, would
it really SOLVE anything, apart from the complaint about losing your prefs if
you go to a different computer setup?  I cannot think of ANY user prefs offhand
(besides the login info) that Bugzilla needs to keep track of, and IMHO, having
the server remember this info would be MORE of a security risk than even client-
side mechanisms.  Think about it: If the server kept this info, then take as an
extreme example, someone who might use a public Internet terminal, like one in a
public library, or an Internet kiosk: what is to prevent ANYONE from using your
Bugzilla account once you've logged in?  That is VERY bad, IMHO.

And how about the general security/privacy concerns some people have about
Cookies?  Most of these concerns, in my experience, turn out to be
misunderstandings about how cookies work, or are just completely unfounded.
IMHO, if cookies are done correctly, there should be no problem.  After all, all
a cookie is is a bit of text stored on the client-side, to allow state
information to be communicated to the server in an otherwise stateless HTTP
protocol.  Yes, there are other bug tracking systems out there, like Jitterbug,
or the Debian bug tracker, that do not use cookies, but those systems suffer for
it.  They are not as easy to use as Bugzilla.

Just my 2 cents.
If you don't log out of your Bugzilla account people can do a lot worse than
using your preference cookies, right now.

The cookies themselves don't worry me, I just don't like having two sets of
bookmarks and preferences.

Also, I think there should be a fourth setting "Bug Fix", for people who don't
want all the comments.  They'd just get "Fixed", "Invalid", "Reopened", etc
messages.
Coincidentally, while trying to add myself to the CC list for this bug, I

accidentally (almost) deleted zuperdee from the list ...
I've talked about things like "bug fix only"/"all" notification triggers on bug
#14137.
Status: NEW → ASSIGNED
Priority: P3 → P2
Of course, voting is a limited form of BCC, but you can only BCC five bugs and
you might want to BCC on something you don't want to vote for.

However, voting does have the important BCC properties of not sending out
notifications and not changing the bug's last changed date, since neither voting
nor BCC are a part of the bug.
QA Contact: matty
I would very much like this implemented. For a start, it was discovered with a 
very popular bug that NS 4.x has a max length on the size of a text box, and if 
the list exceeds it, NS 4.x people can't edit the bug without removing people 
from the list. This feature would solve that problem, as many of those on the 
list would choose to monitor.

Also, over in Browser-General, Asa and I comment to loads of bugs saying "give 
us more info" then have to monitor them for that info. When it arrives we often 
hand it off to some random area and have nothing more to do with it. 
Implementation of this would be a great help in managing that tracking, which 
currently happens with bookmarks and is icky - you have to annotate each one 
with a reminder of what it is by hand.

Gerv
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 .)
Assignee: terry → tara
Status: ASSIGNED → NEW
I'm completely unconvinced as to the value of a BCC field, however, accidental
removal of CC entries or restrictions on number of entries is potentially a real
problem.  Downgrading for now as I haven't seen any screaming about it as far as
lost info.
Status: NEW → ASSIGNED
Priority: P2 → P3
i concur with tara's apprehensions and i'll toss in one more: spammers. I do not 
want to be in the business of trying to remove spammers from cc lists, nor do I 
want bugzilla to become a spamming medium. in order to cc yourself onto a bug, 
you must go through the trouble of creating an account.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Hrm, is it ok for me to verify?
I'm not listed on the CC or the Votes list, but I got the mail [people probably 
will see me as getting the notification]
Notes:
Accidental removal of CC's is no longer an issue, we moved to a CC listbox
Voting doesn't spam [thankfully]
Only you can remove your vote (anyone w/ edit bugs can remove you from the cc 
list)
If you run out of Vote slots we could probably change the vote system to allow 
more votes since it really is being used as a +ru+w cc field.
At worst (although this is probably taboo) you can create another account for 
additional votes (assuming voting isn't used for its main purpose, which up to 
now it hasn't)

In the future voters will have the choice of which notifications to get.

It is true that anyone can cull bugzilla for a list of email addresses, but 
that's a risk you take by using an open system.

wrt Cyeh's comments, i'm confused.
Anyone w/ an account can comment w/o adding themselves to the cc list. a BCC 
field would still have required an account.
Status: RESOLVED → VERIFIED
I have no idea what cyeh is talking about either.

Spammers would have *more* luck farming addresses with the current system.  And
indeed that's an excellent reason why this _should_ to be done!  (although I
believe there are plenty of other ways)!  Privacy should be at least an option.

This bug has nothing to do with adding CCs without accounts.

I have heard no real reasons why it should not be implemented other than no-one
wants to.  And that doesn't qualify it for a WONTFIX designation.

The voting notification stuff is irrelevant as well because I'm pretty sure this
was submitted before voting was implemented!
imo voting and watching are sufficient substitutes for bcc hence voting 
happening _after_ this bug is relevant
Neither voting or watching is a sufficient substitute here.

Voting is not private and it is limited to a specific number of bugs.

Watching will bring in a whole heap of other stuff, and it's not entirely
private either since you see who the notifications get sent to.

An alternative to this is to let users set a "private" flag and just use the CC
field.
*** Bug 93960 has been marked as a duplicate of this bug. ***
Just realized I had filed a dup of this bug.  Maybe if I had an infinite amount
of votes, I would be satisfied.  But that would water down the usefulness of the
votes themselves.
As noted above, keeping track of bugs with bookmarks isn't satisfactory.  Until
today, I had a list of bugs I was keeping track of today.  The list reached 30,
most of which are not being actively worked on.  Checking to see what had
changed every (couple of) day(s) was a chore.
Therefore, today I CC'd myself on all of them.  Some high profile developers
probably got at least 20 mails just from me today.  I really don't think it
helped their productivity very much.  While I can't think of what it would be,
there is probably a good reason that some of them still have notification on.
I have no desire to use three or four different bugzilla accounts just to watch
the progress on bugs I'm interested in.  Please look into some type of solution
here, it will save quite a headache I'm sure.  (As well as offering another
implementation solution for my RFE bug 93957 </plug>)
Many developers tell bugzilla not to send e-mail when the only change to a bug
is someone adding themselves to CC, so you don't have to worry about spamming
them, as long as you leave the comment field blank when you're just CCing yourself.
(http://bugzilla.mozilla.org/userprefs.cgi?bank=diffs)
I was going to note that i actually have a bookmarkesque way of watching bugs, 
you can see it in the form of bug 79119 and bug 79120 they are just meta bugs. 
I can quickly find out which of the bugs depending on them are fixed or 
reopened by clicking on the dependency links, and i added a url to each to 
check for open bugs w/ patches. Dependencies only cause mail if the 
dependency is changed or when a bug's status or resolution changes.
moving to Bugzilla product
reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE
Assignee: tara → justdave
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.