View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004574 | mantisbt | public | 2004-09-17 04:48 | 2019-12-03 07:13 | |
Reporter | whereisglenn | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Summary | 0004574: Limit one email per bug update until user views the bug | ||||
Description | As activity and use of the program grows I find that the number of emails sent from the bugtracker rival our levels of SPAM. It would be a nice feature to limit one email per user per bug until that bug is viewed by the user. Hence further changes to the bug are not reported since the first change notified by the bugtracker. This feature would reset each time the user views the bug. | ||||
Tags | No tags attached. | ||||
related to | 0007239 | new | limit emails sent to user based on last login time |
I think that this would add a lot of overhead to sending emails. Each email sent would require a number of database lookups to see if the potential recipient had looked at the message. An alternative would be to use the existing filter to stop most of the messages. Those outsiders (not reporter or handler) could monitor the issue or contribute a bugnote to see progress. For example, based on the default $g_default_notify_flags:
With these settings, the reporter, plus DEVELOPERs and MANAGERs get notice of a new issue. From there on, only the reporter, handler, those monitoring, or those that have contributed bugnotes will get messages. edited on: 09-17-04 09:41 |
|
Agreed there is certainly an overhead involved with database lookups, but then the system will be sending far fewer emails - perhaps 50-200% less. In our development workflow, users are either developer or manager - because just about everyone is a developer. We are finding that in the space of 30 mins there might be 6 comments, some relationships added and maybe a status update. That's 10+ emails to everyone. If the whole team needs to know about the bug or there are some non technical people monitoring the email then they get all 10 emails regardless of whether they happen to be in the office or not , or even participating actively in the issue's progress. If this was an open source implementation the effects present a stronger case because many users cannot respond immediately. If a topic/issue's discussion should progress while a user is offline, then that user recieves X emails notifying the progress of the bug when a single email and link would suffice. This feature is very common in forum software. |
|
We should probably consider this in the 0.20 timeframe. But in the short term, having the first responder change the status from NEW to ACKNOWLEDGED would stop most of the messages as I outlined above. The default defaults in mantis don't send mail to the project team.
|
|
This bug requests the general ability to send a user only one email until they view the bug again; 0007239 specifically requests the ability to handle this on an issue-by-issue (or maybe also project-by-project) basis. |
|