Closed Bug 338200 Opened 18 years ago Closed 16 years ago

Impersonated updates email optionally

Categories

(Bugzilla :: Email Notifications, enhancement)

2.23
x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 23924

People

(Reporter: kbenton, Unassigned)

References

(Depends on 1 open bug)

Details

Bug 204498 introduces the ability to impersonate others in the database,
however, no mechanism was implemented to record that an update was done as an imposter in the logs.  Bug 320177 requests logging for all impersonated updates.  Having thought much about it and after reading a request from powermax_123@gmx.de, it seems reasonable that in certain cases, an administrator would want to turn off email updates for reasons like, the user's email is no longer valid and the large volume of updates would clog up the mail server, the administrator is performing a large volume of updates in a batch on behalf of another user and does not want to spam a large group with each bug update, and there's always the malicious admin.  With logging of impersonated updates, it would be more difficult for an admin to remove his/her tracks.  If we don't provide admins with this functionality, they're going to hack our code anyway.  If we provide it, they're less likely (IMNSHO) to hack the code, but more likely to just turn off the email update (probably forgetting that the imposter's name is being logged).  Those that know enough to figure out how to update the SQL are just going to do what they would do anyway.  Those that don't will have a much more difficult time figuring out how to bluff the system.

It seems to me that this function ought to be disabled by default, though an admin could enable the ability for imposters to disable email.
Changed summary - typo.
Summary: Impersonated updates email optioanlly → Impersonated updates email optionally
Severity: normal → enhancement
I think that it is very usefull to impersonate users without generating E-Mails to the impersonated users, because E-Mails with that content could cause mistrust. Of course generally people should be informed when users are inpersonated by other non-admin-users, but if an admin would like to "debug" a problem, it could be usefull not to inform them, when the admin doesn't mean ill.

So where can I suppress these E-Mails?
A admin doesn't need to impersonate anyone else to perform actions. I see no valid reason to disable emails in this case. That's a WONTFIX for me.
Lets imagine you have got a test installation with data from a productive database. When you Try-&-Error now (insubstantial what exactly), every user will be informed via E-Mail on everything you do and only a few people will check, that these E-Mails are irrelevant, maybe because in the test-installation the correct "From"-parameter is set, so they can see this, but if not, nobody could ever recognize that these E-Mails are meaningless.

It would generally be good to have a possibility to supress sending E-Mails, not just for impersonating users.

This doesn't necessarily need to be configurable within the GUI, just tell me which lines of code need to be commented out.

In my eyes this is anything but a WONTFIX!
(In reply to comment #2)
> So where can I suppress these E-Mails?

There are two ways to do this:
1) Disable email updates during your change, then turn them back on afterward.
2) Write code to make it possible.

Email from Bugzilla is handled in Bugzilla/BugMail.pm.

(In reply to comment #3)
> A admin doesn't need to impersonate anyone else to perform actions. I see no
> valid reason to disable emails in this case. That's a WONTFIX for me.

There are a number of cases where I want to make a large set of changes simultaneously on behalf of a user I'm impersonating but I don't want to email the entire CC list to make an update.  For example, adding one keyword to 150 bugs would cause 150 emails to go out to every recipient (20 per bug) meaning that over 3,000 emails would flow out from Bugzilla because I made one update.  If most of the people CC'ed on the bug don't care about the flag, I'd have a bunch of people rightfully complaining to me about getting 150 emails.  I don't need that headache.

o) I don't want to be credited with originating the change since so-and-so asked me to make it for them.
o) I don't want to send emails to the entire list of recipients on a bug because they already see Bugzilla as a program that sends too much email already (their words, not mine).
o) Since so-and-so is probably on the phone with me requesting the update, or they're sitting in my office asking me to make the change, I want to be able to give them what they need without annoying the CC list.
o) The people that really need to know about the updates are using RSS to keep track of the bug.

If we're worried about administrators being malicious with updates on behalf of others, as I mentioned in Bug 320177, I think that impersonated updates should be logged.  Admins that know how to delete those log entries that really want to be malicious will be able to delete the logs or make the updates themselves without help from the UI.  Making this kind of change possible from the UI, however, will (in my mind) make it possible for admins to do their jobs more easily while preventing malicious changes (malicious users generally tend to be pretty lazy about covering their tracks).  By making this bug depend on 320177, I suggested that we not attempt this bug till 320177 has been implemented, therefore, requiring that the updates are logged before no email is allowed to flow.
> There are two ways to do this:
> 1) Disable email updates during your change, then turn them back on afterward.
AFAIK I only can change these settings for my account. But every other person will still be mailed, correct? So which benefit would that have? Only I wouldn't get those mails...

> 2) Write code to make it possible.
Obviously...

> Email from Bugzilla is handled in Bugzilla/BugMail.pm.
I haven't looked at this exaktly, but I can imagine that somewhere in this file there is a central call of a function called e.g. "sendmail(...)".
1. Is this correct? Where can this line be found?
2. Would it be enough to comment this line out to supress ALL emails from Bugzilla?


> because they already see Bugzilla as a program that sends too much email
> already (their words, not mine).
Thats exactly my experience. And now explain to any user that you have got an identical test installation of Bugzilla with the same data (e.g. for testing updates or several patches) and that he or she can ignore eMails beeing sent from "bugzilla-test-daemon@...". Nobody, or almost nobody will get the difference!

> I suggested that we not attempt this bug till 320177 has been implemented,
> therefore, requiring that the updates are logged before no email is allowed to
> flow.
IMHO those bugs are completely independant from each other. As Kevin said, we can't prevent admins from hacking the DB. You all assume that the admin(s) of Bugzilla installations all want to do bad things. If I would like to do "bad" things in Bugzilla, I would change the Domain-Password of the user I want to annoy, then I would log into Bugzilla (via LDAP) and would write anything I want to...without "officially" sudoing him or her. So whats the point? If you would like to have a comprehensible trace of Bugzilla-actions you need to log anything including ip, mac-address, etc. These table would need to be encrypted and read-only. And even this wouldn't be enough because at least the admin need to have the decryption password. In my eyes you can never prevent an admin from doing bad things. So why should it be made "harder" to do bad things?
I believe that Bug 23924 deals with this in a much more meaningful/elegant way - when an update is supposed to go out, only send one emai.

(In reply to comment #4)
> Lets imagine you have got a test installation with data from a productive
> database. When you Try-&-Error now (insubstantial what exactly), every user
> will be informed via E-Mail on everything you do and only a few people will
> check, that these E-Mails are irrelevant, maybe because in the
> test-installation the correct "From"-parameter is set, so they can see this,
> but if not, nobody could ever recognize that these E-Mails are meaningless.
> 
> It would generally be good to have a possibility to supress sending E-Mails,
> not just for impersonating users.
> 
> This doesn't necessarily need to be configurable within the GUI, just tell me
> which lines of code need to be commented out.
> 
> In my eyes this is anything but a WONTFIX!
> 

I believe that you can turn off emails from your test installaton to get around that by setting the maildeliverymethod parameter to 'None'

I also read your argument for allowing the ability to turn off email notifications while impersonating, however, I think *that* will do more to create distrust than making sure users are empowered to make meaningful updates (change multiple bugs at once) while only sending a single email per update, not a single email per bug update.  From my experience, that'll take care of the largest part of the need for the checkbox.  Therefore, resolving as a duplicate of bug 23924.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.