View Issue Details

IDProjectCategoryView StatusLast Update
0019977mantisbtplug-inspublic2017-01-24 16:48
Reporterlbredenkamp Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Product Version1.2.19 
Summary0019977: Add event "SENT_BUG_INFO_TO_ONE_USER"
Description

I am working on a plugin which allows users to configure a secondary email address to which all their issue-related emails are sent additionally. This could be a colleague or a group email.

To be able to hook into emails sent to individual users I had to add an event in email_api.php in function email_bug_info_to_one_user at the end.

Some event like this would be very helpful as a standard feature:
event_signal( 'EVENT_SENT_BUG_INFO_TO_ONE_USER', array( $p_user_id, $t_subject, $t_message, $t_mail_headers, $p_project_id ) );

TagsNo tags attached.

Relationships

related to 0010207 feedback Allow multiple valids emails address per account (patch attached) 
related to 0022225 new New Event to change email address of a user by project 

Activities

atrol

atrol

2015-08-06 17:30

developer   ~0051212

email_store would be a better place than email_bug_info_to_one_user as the event would also be triggered when sending reminders.

vboctor

vboctor

2015-08-09 23:52

manager   ~0051218

email_store() is used for emails that are not bug related, so that would not be compatible with the purpose of the event, where only issue related emails are processed.

Why did you choose email_bug_info_to_one_user() as opposed to email_collect_recipients()? It would make sense for an event to extend the functionality that determines the recipients.

atrol

atrol

2015-08-10 02:59

developer   ~0051219

email_store() is used for emails that are not bug related
email_store() is also used for bug related emails.
But you are right, this is not what is wanted/needed at this place.

The event would also have to be added to function email_bug_reminder to get the reminder emails to the additional address.

email_bug_info_to_one_user() as opposed to email_collect_recipients()?
email_collect_recipients allows to add additional user id's but not email addresses.
This might not be what is wanted as group email has also been requested.
Of course, you could add a user as a representative of a group.

Implementing 0010207 in core could be another approach for it.

cproensa

cproensa

2015-09-01 07:41

developer   ~0051339

I think is useful to add a event chain to modify recipient list
placed in email_generic(), after $t_recipients is populated

with parameters: $p_bug_id, $p_notify_type, $t_recipients (maybe $t_recipients too)
then i could use a plugin to add (or remove) custom recipients based on the notifiacion type and bug affected

cproensa

cproensa

2015-09-01 07:42

developer   ~0051340

corrected:

with parameters: $p_bug_id, $p_notify_type, $t_recipients (maybe $p_message_id too)

atrol

atrol

2015-09-01 14:20

developer   ~0051343

placed in email_generic()
If you want it at this place you could use the existing EVENT_NOTIFY_USER_INCLUDE and EVENT_NOTIFY_USER_EXCLUDE in function email_collect_recipients

cproensa

cproensa

2015-09-02 03:59

developer   ~0051351

Hello atrol, there is a problem with those events
after EVENT_NOTIFY_USER_INCLUDE, the function email_collect_recipients cleans up the recipient list, excluding any user that does not meet access leves or notification preferences.
Seems not possible to add an arbitrary recipient without it getting filtered by the standard checks.

May the squence of events should be, changing the position of those events:

  • function builds up user list
  • EVENT_NOTIFY_USER_EXCLUDE
  • function excludes by access level, prefs, etc
  • EVENT_NOTIFY_USER_INCLUDE

Or add a final event like: EVENT_NOTIFY_USER_INCLUDE_NOCHECKS

atrol

atrol

2015-09-02 06:00

developer   ~0051356

You proposal would allow plugins to violate the rules that have been setup by the Mantis administrator (access levels) and to bypass issue settings like "private" view status.

Changing data after it has been validated is never a good idea.

cproensa

cproensa

2015-09-02 06:29

developer   ~0051357

you are right, is not a good idea

but, what if i need a different behaviour?
For example: i want user monitoring to receive status updates afer the bug has been moved to another project (which the monitoring user has no access)

A chain event to process the recipients_list?