View Issue Details

IDProjectCategoryView StatusLast Update
0004574mantisbtemailpublic2019-12-03 07:13
Reporterwhereisglenn Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Summary0004574: 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.

TagsNo tags attached.

Relationships

related to 0007239 new limit emails sent to user based on last login time 

Activities

thraxisp

thraxisp

2004-09-17 09:40

reporter   ~0007634

Last edited: 2004-09-17 09:41

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:


$g_notify_flags['new']['threshold_min'] = DEVELOPER;
$g_notify_flags['new']['threshold_max'] = MANAGER;

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

whereisglenn

whereisglenn

2004-09-17 10:02

reporter   ~0007636

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.

thraxisp

thraxisp

2004-09-17 10:38

reporter   ~0007637

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.


$g_default_notify_flags = array('reporter' => ON,
'handler' => ON,
'monitor' => ON,
'bugnotes' => ON,
'threshold_min' => NOBODY,
'threshold_max' => NOBODY);

ryandesign

ryandesign

2006-07-26 09:24

reporter   ~0013148

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.