View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0009350||mantisbt||plug-ins||public||2008-07-05 18:55||2014-06-20 08:28|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0009350: Support plugins for micro notifications|
Mantis currently support integration with Twitter as a target for micro updates like resolving issues, news, etc.
The aim of this work item is to do the following:
It might be beneficial to rework all notifications in Mantis to use some sort of Notification object that stores the appropriate data, and then can be interpreted by multiple sets of code, so that things such as email notifications, twitter updates, or SMS messages can all build from a single information source. The object should be as generic as possible, and allow for system-wide, project-specific, or issue-specific notifications. The object could then be interrogated by the receiver to determine which users should be notified, and then leave it to the receiver to determine how to contact the users.
It would probably be easiest to create EVENT_NOTIFICATION, and have the a core API hook the event to generate emails, while also allowing other plugins to hook the event, or even generate their own custom notifications and trigger the notification event on their own as well. This would also be useful for things such as the Source Integration plugins, so that notifications can be generated when someone checks in code relating to a bug you are monitoring, etc.
I agree with your suggestion, and I wanted to take this approach sometime ago. We can roll the micro-notifications approach in by generating some specific events.
I was also lately thinking that our emails should include information about the event that happened rather than the full issue detials. For example, the note that was added, the relationship that was added, etc. This can be done if we pass more information as part of the notification structure.
I'll roll a wiki page with some details on how I see it being implemented. I'd like to stick with a single object and a single event, but design it in a way such that any API/plugin can use it as needed to generate any sort of notification as necessary. I'd rather see a simple interface that requires a bit more decision on the part of plugins to generate appropriate notifications than have a complex API with numerous events.
Targetting next major version.
grangeway basically implemented step 1 when he removed the twitter API from master branch (it was in any case broken since Twitter switched to OAuth and removed basic auth support).
MantisBT: master cd3e0ed2
Paul RichardsDetails Diff
|Remove Twitter code from Mantis Core that no longer works due to twitter's deprecation of username passwords||
|mod - bug_update.php||Diff File|
|mod - config_defaults_inc.php||Diff File|
|mod - core/bug_api.php||Diff File|
|mod - core/config_api.php||Diff File|
|mod - core/constant_inc.php||Diff File|
|mod - core/email_api.php||Diff File|
|mod - core/news_api.php||Diff File|
|rm - core/twitter_api.php||Diff File|
|2008-07-05 18:55||vboctor||New Issue|
|2008-07-07 09:50||jreese||Note Added: 0018324|
|2008-07-07 12:19||vboctor||Note Added: 0018327|
|2008-07-07 14:11||jreese||Note Added: 0018330|
|2008-07-15 15:38||grangeway||Tag Attached: plugin framework|
|2008-07-15 15:38||grangeway||Status||new => confirmed|
|2008-11-14 14:21||jreese||Note Added: 0019899|
|2008-11-14 14:21||jreese||Target Version||=> 1.x.x|
|2008-12-02 15:03||grangeway||Product Version||CVS HEAD =>|
|2014-01-21 16:45||atrol||Target Version||1.3.0-beta.1 =>|
|2014-06-20 08:22||dregad||Note Added: 0040838|
|2014-06-20 08:23||dregad||Relationship added||related to 0010481|
|2014-06-20 08:25||dregad||Relationship added||has duplicate 0012865|
|2014-06-20 08:27||dregad||Relationship added||related to 0017384|
|2014-06-20 08:28||dregad||Changeset attached||=> MantisBT master cd3e0ed2|
|2014-06-20 08:28||dregad||Note Edited: 0040838||View Revisions|