View Issue Details

IDProjectCategoryView StatusLast Update
0010226mantisbtemailpublic2014-12-08 00:34
ReporterjonathhAssigned Todhx 
Status closedResolutionfixed 
Product Version1.1.6 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0010226: No email on 'update->assign'

No assignment emails are fired off when you use the 'update issue' then 'assign' as opposed to using the 'assign to' process.

TagsNo tags attached.


related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 
has duplicate 0006640 closeddhx No email sent when issue assigned through change status 
child of 0012097 closedatrol Tracking issue for the refactoring of bug_update.php 




2009-05-27 11:03

reporter   ~0021939

Anyone had a look at this issue yet? It is a real thorn!



2009-05-30 12:52

reporter   ~0021982

If you are able, can you see if this still occurs with the git trunk code? (from / )



2009-07-29 05:04

reporter   ~0022594

@grangeway: Sorry, can't test with git trunk as I am not running PHP 5.3

@jonathh: This is because Mantis uses the user email preferences for email_on_status instead of email_on_assigned (account_prefs_page.php). You can correct this behaviour on version 1.1.6 by adding one line to function email_collect_recipients in core\email_api.php:

unset( $t_statuschange[NEW] );
unset( $t_status_change[FEEDBACK] );
unset( $t_status_change[RESOLVED] );
unset( $t_status_change[CLOSED] );

unset( $t_statuschange[NEW] );
unset( $t_status_change[FEEDBACK] );
unset( $t_status_change[ASSIGNED] ); # <-- new line
unset( $t_status_change[RESOLVED] );
unset( $t_status_change[CLOSED] );

Hope that helps,



2009-07-29 05:22

reporter   ~0022595

Thank you, I have tested that in our 1.1.6 'Play Area' and it seems to work. Our main area is now at 1.1.8 do you know of any reason why this fix would not work there?

Also, will this fix be in the next release?

Thank you so much!



2009-07-29 06:07

reporter   ~0022597

I just had a quick look at file changes 1.1.6->1.1.8 and found no reason why it shouldn't work - but I do not have a running 1.1.8 system...

Regarding future versions: There have been heaps of changes (also in this area), but at a first glance I couldn't find a change fixing this in 1.2.0rc1.
But again: I do not have a running 1.2.x system either...
BTW: reason could also been seen in function (bug_)update (lines 520ff in 1.2.0rc1) core\bug_api.php where "status change" is checked before "assignement" - so another solution would be to move lines 527-531 to line 519

@grangeway: Could you please verify?




2009-07-29 06:14

reporter   ~0022598

Well I bit the bullet and applied to our 1.1.8 environment and it WORKS. Just FYI.

Thank you!



2009-07-31 13:19

reporter   ~0022641

I'll assume this is something that was fixed between 1.1.6 and 1.1.8 so marking resolved.



2009-07-31 14:29

reporter   ~0022643

@grangeway: This is IMHO a big misunderstanding. What jonathh meant was, please correct me if I'm mistaking, that the patch I posted also works for 1.1.8 ...

@jonathh: Did I understand your comment right?



2009-08-01 05:20

reporter   ~0022644

@floh: i understood it the same as you did; the same patch (adding unset( $t_status_change[ASSIGNED] ); # <-- new line) works for 1.1.8 as well as for 1.1.6, but does not appear in either of them



2009-08-03 04:25

reporter   ~0022647

grangeway, you are mistaken. I applied the fix to both 1.1.6 and 1.1.7 and that fixed it. The bug is most definitely present in vanilla 1.1.8.



2009-08-06 16:33

reporter   ~0022678


Can you see if there's something needed in the 1.1 branch here.




2009-08-07 02:06

reporter   ~0022689

Here some more notes which maybe clarifies the unexpected behaviour:
1) it appears on any status change to assigned using bugupdate(advanced_)page.php
2) the "root" is that using this way the assignment is considered a "status change" instead of an assignment (unlike all other ways to assign an issue). Therefore email_collect_recipients uses the user email preferences for email_on_status (defaults to off) and not email_on_assigned (defaults to on)
3) as far as I read the code it applies as well to 1.1.x branch as to 1.2.x branch (but jonathh and me could only test it for 1.1.6 to 1.1.8)
4) possible fixes are described in my notes 0022594 and 0022597




2009-08-07 04:08

reporter   ~0022692

In 1.2.x, unset( $t_status_change[ASSIGNED] ); is invalid as per:

@@@ thraxisp note that email_on_assigned was co-opted to handle change in handler

In other words, there used to be an "E-mail on Assigned" preference, but it was renamed/retasked to be "E-mail on Change of Handler" instead.

If you try to unset ASSIGNED from that array, you won't get emails when the status is changed to 'assigned'.

email_generic() should be called with the second parameter being 'owner' whenever you change the assignee/handler of a bug. If you're only changing the status to 'assigned' (without changing the assignee/handler) then email_generic() should be called with the second argument as the new status... 'assigned'.

Note that email notifications based on status changes are NOT user configurable within Mantis (yet). This annoys me a lot too! The notification system within Mantis is in desperate need of a complete overhaul.



2009-08-14 08:53

reporter   ~0022727

Meanwihle I had a chance to test emails with 1.2.0rc1:
same problem, same solutions



2009-08-14 08:56

reporter   ~0022729

Please try the latest 1.2.x git master, I may have "fixed" this problem in;a=commitdiff;h=33a8395ebebb972bd03849e6136cff0461a924e6



2009-08-14 16:01

reporter   ~0022735

Great to see someone is working on this.
So far your changes haven't fixed 0010226, but if you enhance
case 'bugnote':
$t_pref_field = 'emailon' . $p_notify_type;
case 'owner':

The email_on_assigned notification type is now effectively

        # email_on_change_of_handler.
        $t_pref_field = 'email_on_assigned';



case 'bugnote':
$t_pref_field = 'emailon' . $p_notify_type;
case 'owner':
case 'assigned': # <-------ADDED LINE (floh)

The email_on_assigned notification type is now effectively

        # email_on_change_of_handler.
        $t_pref_field = 'email_on_assigned';


it does the trick. Can you please check and then commit to git?

Kind regards, floh



2009-09-15 10:02

reporter   ~0022933

I understand what you've attempted to do with your patch, but the 'assigned' case is incorrect where you've placed it. It assumes that every Mantis installation uses the default 'assigned' status for issues that have been assigned to a developer. This is not true, as Mantis can be configured with custom statuses where the assigned status becomes something else like 'triaged'.

When the bug_assign function is called, the email_collect_recipients function is called with the notification type argument set to 'owner'. This correlates directly with the "Email on Change of Handler" user account preference.

The problem is that bug_assign is NOT called in many instances where the assignee field is changed. Therefore the "Email on status change" user preference will come into effect... not "Email on change of handler". I hope you can now see how these two preferences (and most of the other ones too) overlap.

In short, the notification system is a complete mess and needs a huge overhaul.



2013-04-05 17:57

reporter   ~0036500

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master 035a1302

2010-06-23 00:44:38


Details Diff
Refactor bug_update to fix multiple bugs

This is a large change to bug_update.php which refactors the code to
make it clearer and easier to understand. More importantly this
refactoring fixes a number of bugs including the prior ability for
reporters (with allow_reporter_reopen enabled) to make any modifications
to the bug in question even when they didn't have permission to make
those changes.

This refactoring brings about a structural change to the bug update
process. Previously the update checked a field (or number of fields) and
then committed changes to the database before moving on to the next
field. Hence it was possible for some of the requested changes to be
committed to the database before a validation error kicked in,
preventing the remainder of updates from being committed.

The new structure of bug_update prevents partial commits from occurring
as all validation and access checks are done prior to ANY data being
committed to the database. If all the validation checks pass then the
user can be safe in knowing that all changes should be committed to the
database. If any of the validation checks fail, none of the changes have
been committed.

One remaining problem with this approach is the race condition whereby
the administrator updates access checks between the validation of a
field and the attempted committal of a field to the database. As access
checks are performed internally within bug_api (and elsewhere), these
could actually fail during committal (and after the validation steps in
bug_update) if the access levels have changed in the meantime. This is a
problem with requires rewriting much of the MantisBT codebase - all for
a problem that is unlikely to occur and which is of low severity.

Email notifications also need to be sorted out correctly some time in
the future as it is hard to determine what the expected course of action
should be. This update tries sending an email in this order: resolved,
closed, reopened, handler added, status changed, bug updated. Only one
email is sent so if the handler and status of an issue are updated at
once and a user has refused to receive handler notifications, they won't
get any email. This is because we currently give higher priority to
notifying users of the addition of a handler to an issue rather than a
change of status.

Issue 0012097: Refactor bug_update.php
Fixes 0009828: Reopen issue access check is wrong
Fixes 0010226: No email on 'update->assign'
Fixes 0011396: difference between closed and resolved
Fixes 0011804: allow_reporter_reopen lets reporter make any update
mod - bug_update.php Diff File

Issue History

Date Modified Username Field Change
2009-03-18 10:35 jonathh New Issue
2009-05-27 11:03 jonathh Note Added: 0021939
2009-05-30 12:52 grangeway Note Added: 0021982
2009-07-29 05:04 floh Note Added: 0022594
2009-07-29 05:22 jonathh Note Added: 0022595
2009-07-29 06:07 floh Note Added: 0022597
2009-07-29 06:14 jonathh Note Added: 0022598
2009-07-31 13:19 grangeway Note Added: 0022641
2009-07-31 13:19 grangeway Status new => resolved
2009-07-31 13:19 grangeway Resolution open => no change required
2009-07-31 13:19 grangeway Assigned To => grangeway
2009-07-31 14:29 floh Note Added: 0022643
2009-08-01 05:20 yw84ever Note Added: 0022644
2009-08-03 04:25 jonathh Note Added: 0022647
2009-08-06 16:33 grangeway Status resolved => assigned
2009-08-06 16:33 grangeway Assigned To grangeway => jreese
2009-08-06 16:33 grangeway Note Added: 0022678
2009-08-07 02:06 floh Note Added: 0022689
2009-08-07 04:08 dhx Note Added: 0022692
2009-08-14 08:53 floh Note Added: 0022727
2009-08-14 08:56 dhx Note Added: 0022729
2009-08-14 16:01 floh Note Added: 0022735
2009-09-15 10:02 dhx Note Added: 0022933
2009-12-03 10:07 jreese Assigned To jreese => dhx
2010-06-19 01:07 dhx Relationship added child of 0012097
2010-06-19 01:21 dhx Relationship added has duplicate 0006640
2010-06-22 21:40 dhx Changeset attached => MantisBT master 035a1302
2010-06-22 21:40 dhx Resolution no change required => fixed
2010-06-22 21:40 dhx Fixed in Version => 1.3.0-beta.1
2010-06-22 22:48 dhx Target Version => 1.3.0-beta.1
2010-06-22 22:49 dhx Status assigned => resolved
2013-04-05 17:57 grangeway Status resolved => acknowledged
2013-04-05 17:57 grangeway Note Added: 0036500
2013-04-05 18:05 grangeway Relationship added related to 0015721
2013-04-06 03:44 dregad Status acknowledged => resolved
2013-04-06 07:20 grangeway Status resolved => acknowledged
2013-04-06 09:26 dregad Tag Attached: 2.0.x check
2013-04-06 09:26 dregad Status acknowledged => resolved
2014-09-23 18:05 grangeway Tag Detached: 2.0.x check
2014-12-08 00:34 vboctor Status resolved => closed