View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0019977 | mantisbt | plug-ins | public | 2015-07-27 12:28 | 2017-01-24 16:48 |
Reporter | lbredenkamp | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 1.2.19 | ||||
Summary | 0019977: 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: | ||||
Tags | No tags attached. | ||||
email_store would be a better place than email_bug_info_to_one_user as the event would also be triggered when sending reminders. |
|
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. |
|
The event would also have to be added to function email_bug_reminder to get the reminder emails to the additional address.
Implementing 0010207 in core could be another approach for it. |
|
I think is useful to add a event chain to modify recipient list with parameters: $p_bug_id, $p_notify_type, $t_recipients (maybe $t_recipients too) |
|
corrected: with parameters: $p_bug_id, $p_notify_type, $t_recipients (maybe $p_message_id too) |
|
|
|
Hello atrol, there is a problem with those events May the squence of events should be, changing the position of those events:
Or add a final event like: EVENT_NOTIFY_USER_INCLUDE_NOCHECKS |
|
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. |
|
you are right, is not a good idea but, what if i need a different behaviour? A chain event to process the recipients_list? |
|