Maybe this issue is related to 0008928?

Can someone take a look?

Another example: When I request feedback and assign at the same time, the email says "The following issue has been ASSIGNED" instead of "The following issue requires your FEEDBACK."

From "Steps to Reproduce" and latest Note

adding a note AND selecting a user to assign the issue to.
When I request feedback and assign

Both examples include assignment to a user.
IMO assignment has a higher priority than request for feedback, so there is nothing wrong when sending email "The following issue has been ASSIGNED"

What do you think?

When you click to "Change status to: XXX" you want to inform that the issue have a new status, regardless of having someone assigned to. Because of that, IMO, ASSIGNMENT is lower priority than the other status changes.

If you want to request feedback (or change the issue status to whatever), the user has to know it. If he opens an email and sees "The following issue has been ASSIGNED" he'll think that the issue is being handled, which is not the case. The same when confirming an issue, and so on.

Seems we use MantisBT for different workflows.

What does "request feedback" mean for you?
Do you want feedback from the original reporter (customer, user from quality assurance) of the issue?

What does "assigned user" mean for you?
I use it as some kind of "the person who is responsible for the issue" (typically support users when using MantisBT for external customers, typically developers when using MantisBT for internal tests)
That's why I see assignment as high priority.

"Request feedback" means that we want feedback from the original reporter.

"Assigned user" means "the person" (developer or tech support) who is handling the issue.

That's really why I see "request feedback" has higher priority than "assigned". The original reporter needs to know that "he has to do something" instead of "someone is doing something"

Maybe we should send different emails if reporter and assigned user are not the same.

"The following issue has been ASSIGNED" to the assigned user and all other involved users.
"The following issue requires your FEEDBACK." to the reporter.
If reporter (can be a developer) and assigned user are the same send "The following issue has been ASSIGNED"

But how to deal with the following use case:
Reporter is user R1, assigned is user A1 and you request feedback and change assigned to A2 in one step?
Do you want feedback from R1 or A2?

I see it now.

I agree with you about different emails, but disagree on your point: 'If reporter (can be a developer) and assigned user are the same send "The following issue has been ASSIGNED"'. IMO you should send "The following issue requires your FEEDBACK" to the reporter every time.

The rule can be:

• always send "has been ASSIGNED" to assigned user;
• always send "has been NEW STATUS" or "requires your FEEDBACK" to reporter.
• if assigned == reporter, send both.

About the given scenario, "My View" answers you question. "Awaiting Feedback from Me" filter is: reporter = R1, status = feedback. It ignores the assigned user. Now if you do want feedback from A2, I don't know. Maybe this is a different use case not currently supported by Mantis.

edit1: added info;
edit2: typo.

@atrol any thoughts about this?

Our discussion might become a neverending story because the concept of MantisBT is not complete clean and consistent concerning status and handler.

e.g.
You can have set status to "assigned" without having a handler assigned.
There is no hardcoded meaning of status "FEEDBACK" in a way that it always means feedback from reporter.

You can have your own rule how to request feedback:

• by setting status to feedback without assigning or changing the handler, add a note
• by setting status to feedback, change the handler, add a note
• by setting status to assigned, change the handler, add a note

Your rule

• always send "has been NEW STATUS" or "requires your FEEDBACK" to reporter.
  is complete another one than the one which is described in MantisBT administrators guide for the usage of feedback

"Resolved - This status is used to reflect that the issue has been resolved. ... The next statuses are typically "closed" or in case of the issue being RE-OPENED, THEN IT WOULD BE "FEEDBACK"."

Typically reporters are reopening issues and the feedback is requested from developer.

It seems we would need even more configuration options to cover the different workflows.

All in all, not likely to happen very soon without a contribution. (e.g. a pull request for master branch)

Well, actually the "feedback" was just a example, and this other discussion came out because I hadn't enough knowledge about MantisBT at that time and I didn't expressed myself well. It's really hard to cover different workflows with the current configuration options. Do you know if there is any consistent discussion on the mailing list or the forum regarding this?

Back to the issue and answering 0013485:0032164, the situation I run into is, when updating a issue, "handler changed" has higher priority than any status change for email sending. (core/bug_api.php#533)

Rewriting my suggestion (0013485:0032296):

According to "E-mail Notifications page" configuration:

• always send "has been ASSIGNED" to users set on "E-mail on Change of Handler"; and
• always send "NEW STATUS" to users set on "Status changes to...";

This would generate two emails when changing status AND handler at the same time. But IMO is better than sending "has been ASSIGNED" when eg. resolving an issue.

Sending 2 emails for what frequently is (or at least, can be) the same single event is not an option - mantis can generate enough spam as it is.

Debating which event has highest precedence would be an endless discussion due to diverging requirements and opinions.

Imo a better option would be to change the email notifications to include a "recent changes" e.g see 0000895.

I am a bit double-minded.
I was the one who changed precedence when fixing 0012217 [1]
If we change it back, we would not get any longer the assigned message.

Maybe it's better to have a bit more spam (which can be reduced by account settings) instead of not getting notified

So what about something like

$t_email_sent = false;

bug assigned
        if( $t_old_data->handler_id != $this->handler_id ) {
            email_generic( $c_bug_id, 'owner', 'email_notification_title_for_action_bug_assigned' );
            $t_email_sent = true;
        }

        # status changed
        if( $t_old_data->status != $this->status ) {
            $t_status = MantisEnum::getLabel( config_get( 'status_enum_string' ), $this->status );
            $t_status = str_replace( ' ', '_', $t_status );
            email_generic( $c_bug_id, $t_status, 'email_notification_title_for_status_bug_' . $t_status );
            $t_email_sent = true;
        }

        # @todo handle priority change if it requires special handling
        # generic update notification
        if ( !$t_email_sent ) email_generic( $c_bug_id, 'updated', 'email_notification_title_for_action_bug_updated' );

I still don't think it's a good idea to send 2 mails for the same update.

We can use the 2 strategies with configuration options (2 emails OR single diff).

While 0000895 is on hold, what about creating a configuration option to "Always send emails on change of handler"? With this option turned ON, emails should be sent like @atrol's logic above. IMO, 'action_bug_updated' emails should also be sent too (on his logic --and on the current Mantis'-- these emails aren't sent if handler is changed).

What are most intriguing for me is: why "handler changed" is SO important that it overrides every other changes?

TBH, I don't ever read the other changes when I read "The following issue has been WHATEVER".