View Issue Details

IDProjectCategoryView StatusLast Update
0007310mantisbtemailpublic2018-12-15 14:36
Reporterreal2real Assigned To 
Status confirmedResolutionopen 
Product Version1.0.3 
Summary0007310: no email notification is sent if status are customized

steps to reproduce:
1) create 10 custom status to use instead of new/ feedback/acknowledged/confirmes/Assigned/resolved

2) enable email notification

3) create a bug report

4) no mail is sent !?

Additional Information

the bug has also been reported by someone else :

TagsNo tags attached.


has duplicate 0013031 closedatrol Problem with e-mail for non default statusses 
related to 0009406 assignedvboctor custom status field -> no email notification 
related to 0025090 closedatrol Changing issue's status to a custom status doesn't send email 




2012-11-28 06:05

reporter   ~0034415

Last edited: 2012-11-28 06:05

I also noticed this issue in my implementation (V1.2.5) and did the following work around for email_new_bug:
replace the content of the function email_new_bug by the following LoC:
$t_config_var = config_get( 'status_enum_string');
$t_bug = bug_get($p_bug_id);
$t_status_enum_label = MantisEnum::getLabel( $t_config_var, $t_bug->status );
email_generic( $p_bug_id, $t_status_enum_label, 'email_notification_title_for_action_bug_submitted' );

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.



2015-04-08 02:01

manager   ~0049334

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.



2015-04-08 02:01

manager   ~0049335

Reminder sent to: atrol, dregad

Do you have thoughts on the proposed approaches or other approaches that come to mind?



2015-04-08 17:54

developer   ~0049351

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
but we use the status enum values.

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.



2015-11-06 03:34

reporter   ~0051823

I have the same problem in 1.2.19 release.
When do you fix this bug? Which release? 1.3.0?

Thanks for your answer.



2015-11-06 04:48

developer   ~0051824

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.