View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007310||mantisbt||public||2006-07-26 09:53||2018-12-15 14:36|
|Summary||0007310: no email notification is sent if status are customized|
steps to reproduce:
2) enable email notification
3) create a bug report
4) no mail is sent !?
the bug has also been reported by someone else :
|Tags||No tags attached.|
I also noticed this issue in my implementation (V1.2.5) and did the following work around for email_new_bug:
But this doesn't solve the problem with the other things like email_resolved and so on. One possibility would be to do similar things there, the other would be to change the notify settings array which is saved in DB.
This issue still exists with 1.3.0-beta.2 release. If there is a custom status for newly submitted issues that has a different name, then the bug_report page will send "new" yet the config set in the database by the "email notifications" page won't include "new" but would include the equivalent custom status. This will fallback to default_notify_flags which doesn't send out notifications based on threshold.
We need to figure out an approach to fix this.
Option 1 - continue to use special types like "new" and when evaluating them look for the literal "new" or the configured submission status. Same for other logical statuses that we assume a specific name for.
Option 2 - just replace the call to email api with the configured status name rather than the hard-coded name. This option will fix the issue, but may mismatch with configurations out there.
Reminder sent to: atrol, dregad
Do you have thoughts on the proposed approaches or other approaches that come to mind?
No real idea at the moment what's the best option, seems there is a redesign needed for a clean solution.
Just some hints:
Option 2 might be more consistent as we don't use the hardcoded 'new' action on configuration page, see https://github.com/mantisbt/mantisbt/blob/master/manage_config_email_page.php#L277
Having threshold_min and threshold_max is not consistent with the configuration page where we have check boxes for each access level.
The settings do not correspond with user account settings (user_pref_get) that we set on page account_prefs_inc.php.
I have the same problem in 1.2.19 release.
Thanks for your answer.
Certainly not in 1.2.x branch. As for 1.3.x it seems the logical target but TBH I have other things on my radar at the moment so I can't make any commitment. Maybe @vboctor can comment.
For the record, I agree with atrol's position in 0007310:0049351 below.