Re: [mantisbt-dev] Notifications - going beyond text emails with issue dumps

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Thanks everyone for the feedback.  I've sent out a pull request with the
changes.  The goal is have the work in progress available via this pull
request so that I can get feedback and tweak accordingly.

Here is a sample email about addition of a note:
http://grab.by/ttlg

Paul:

- You already have email template / html support.
[Victor] It would be a good idea to port this to a pull request so that we
can look at it and determine how we can combine both approaches.  Please
don't port directly to master.  We need to only put such big features in
master when we determine that they are ready.

Robert:

- Write the html emails as an extension
[Victor] I can do that once we agree on the approach.  The end result will
be notification events at the core, then plugins can provide email, text,
twitter, jabber, etc.

Manilal:

- Multiple email addresses per user
[Victor] Will not tackle as part of this change.

- HTML emails is super useful and shouldn't include extra information like
bug history
[Victor] That is exactly what this change is about.

Roland:

- Send an embedded picture rather than link to Gravatar?
[Victor] Why?

- Support avatar providers
[Victor] Agreed that we should tackle this at one point via extensibility.

895: bugzilla type diff email instead of full bug each time.
[Victor] The way notifications are currently design will enable that, but
we just need to use a diff algorithm.  The notification handlers now
receive a snapshot of the entity before and after the change.

1400: Feature to send HTML-formatted e-mail instead of text e-mail
[Victor] That's pretty much what the pull request offers right now for some
of the notifications.

3184: differ email notification between reported and monitored bugs
[Victor] We can decide to include the notification reason as part of the
template or in the headers.

3380: E-mail notification on editing bugnotes and adding files
[Victor] I've already added a notification for the note editing, but not
adding files.  This can be added without a problem.  It doesn't affect the
design.  Ideally, we would start capturing the attachment owner in 1.3.x.

3398: Include options for what is sent in an email
[Victor] The concept of templates would allow that.  However, the approach
suggested is to focus on the change and to have minimal other information.

3589: Previous handlers not notified of change of assignment
[Victor] With the suggested notifications design, the before snapshot
includes the old handler and is added as a recipient.

4278: Summary email vs detailed email
[Victor] Instead of making the detail level configuration, I suggest we
just make notifications communicate just the change.

4557: Stop monitoring link in e-mail
[Victor] To implement this we will have to evaluate them template for each
user since users that receive a notification about an issue and are
monitoring should get "stop monitoring" link, others shouldn't.  A simpler
approach would be just to have the user click to open the issue and
unmonitor from there.  I'm leaning towards "won't fix".

5043: Bugnote linking from history/e-mail notification
[Victor] This issue would be resolved by the fact that we would only
include the added note.

5804: Emails / Include purpose of email in header for filtering
[Victor] This is similar to 3184.  I've added a 'related to' relationship.
 Can be easily fixed.

6829: emails design should be improved
[Victor] This is pretty much asking for the change I've included in the
pull request.

7184: Add "changed by" information to the top line of the email
[Victor] That is included in my change.

7239: limit emails sent to user based on last login time
[Victor] That is unrelated to email format.

8986: customized eMail subjects
[Victor] In the changes I've implemented so far, I focused on the
customization of the body based on events, but we can make the subject
customizable using the same technique.

9602: Email Notification with Attachment
[Victor] We should have "file attached" notification.  If so, that would be
the only one where we should consider including the attachment. However,
I'm inclined that unless it is an image, I wouldn't do so.

10207: Allow multiple valid emails address per account
[Victor] Not specifically related to the current change.

12830: new HTMLMail plugin v0.1
[Victor] We can either deliver this functionality natively or as a plugin.
 In both cases, we would use the new notifications object model.

13692: Extending e-mail notifications with a short summary of changed
properties
[Victor] The pull request would address this issue.

On Tue, Jan 7, 2014 at 1:07 PM, Roland Becker <ro...@at...> wrote:

> Avatars:
>         - send as embedded picture not as a link to gravatar
>         - support storage on gravatar or similar / LDAP / Mantis account
>
> There is some user input regarding notifications that is worth to be
> reviewed.
>
> http://www.mantisbt.org/bugs/view.php?id=895
> http://www.mantisbt.org/bugs/view.php?id=3184
> http://www.mantisbt.org/bugs/view.php?id=3380
> http://www.mantisbt.org/bugs/view.php?id=3398
> http://www.mantisbt.org/bugs/view.php?id=3589
> http://www.mantisbt.org/bugs/view.php?id=4278
> http://www.mantisbt.org/bugs/view.php?id=4557
> http://www.mantisbt.org/bugs/view.php?id=5043
> http://www.mantisbt.org/bugs/view.php?id=5804
> http://www.mantisbt.org/bugs/view.php?id=6829
> http://www.mantisbt.org/bugs/view.php?id=7184
> http://www.mantisbt.org/bugs/view.php?id=7239
> http://www.mantisbt.org/bugs/view.php?id=8986
> http://www.mantisbt.org/bugs/view.php?id=9602
> http://www.mantisbt.org/bugs/view.php?id=10207
> http://www.mantisbt.org/bugs/view.php?id=12830
> http://www.mantisbt.org/bugs/view.php?id=13692
>
> Roland
>
> > Manilal K M <ma...@ej...> hat am 6. Januar 2014 um 04:21
> geschrieben:
> >
> >
> > IMHO, HTML Mails and Templates are the highest priority. In most cases,
> the
> > entire issue history is not significant in a notification and users are
> more
> > interested in the changes made to the issue. I guess this can be solved
> by
> > implementing mail templates.
> >
> > It would be really nice if it's possible to have multiple email address
> for
> > users. Most of our employees are contractors/consultants and they have at
> > least 2 email address for official communication. Some of them prefer
> > notifications to be send to their parent company address, while some of
> them
> > would like to receive the notifications in both email address.
> >
> > In addition, it would also be beneficial to EmailReporting plugin users
> since
> > they can send bug reports from multiple email address.
> >
> > regards
> > Manilal
> >
> > ----- Original Message -----
> >
> > > From: "Paul Richards" <pa...@ma...>
> > > To: "developer discussions" <man...@li...>
> > > Sent: Monday, January 6, 2014 2:57:43 AM
> > > Subject: Re: [mantisbt-dev] Notifications - going beyond text emails
> with
> > > issue dumps
> >
> > > Just so you know, I'm in the process of merging my work from
> mantis-2.x for
> > > emails that i have been using in production at work since April 2013
> into
> > > master.
> >
> > > This adds support for html based mails and mail templates.
> >
> > > The commit to tidy up log_event (
> > >
> https://github.com/mantisbt/mantisbt/commit/2d0df25ec0fc7d9a0d97c8e5e102b617e5ff96d9
> > > ) was the start of this process.
> >
> > > For targets such as text messages, twitter etc, those are best handled
> as
> > > plugin's from event triggers.
> >
> > > There is already a Jabber plugin on the mantis-plugins repository.
> >
> > > Paul
> >
> > > On Sun, Jan 5, 2014 at 9:13 PM, Victor Boctor < vb...@gm... >
> wrote:
> >
> > > > I'm looking into improve/modernize the notifications support in
> MantisBT
> > > > (as
> > > > mention on the other thread). My thoughts is to improve on the
> following:
> > >
> >
> > > > - A notification should include all context information about the
> change.
> > > > So
> > > > the code constructing the email has the type of change, and all
> > > > before/after
> > > > information about it. For example, an issue update would have the
> type
> > > > "updated" and the before/after snapshots of the issue.
> > >
> >
> > > > - Notifications format messages based on the event. For example, if
> a user
> > > > comments on an issue, then an email reflecting that user X has
> commented
> > > > in
> > > > issue Y, showing the content issue id, title, comment, avatar of the
> user
> > > > who commented, and link to reply. In other words, don't just rely on
> the
> > > > issue history + first line to understand the kind of change, then
> fish the
> > > > actual change in a long dump of the full message.
> > >
> >
> > > > - Having a representation of the change type and all its related
> > > > information
> > > > allows multiple notification types to process such notifications and
> > > > translate them into html emails, text emails, text messages, twitter
> > > > updates, irc messages, hooks, phone app notifications, etc. Priority
> is
> > > > html
> > > > emails, others are just things to help drive the implementation in
> the
> > > > right
> > > > direction.
> > >
> >
> > > > - A notification has the following artifacts:
> > >
> > > > + trigger - this is where the notification is triggered typically
> from
> > > > bug_api, bugnote_api, etc. (although we have cases where this is
> happening
> > > > from action pages + soap-api).
> > >
> > > > + context - these are the parameters sent to the trigger with
> > > > before/after/change type. The actual notifications may end up using a
> > > > subset
> > > > of the context.
> > >
> > > > + targeting - who should receive this notification? this is the
> logic to
> > > > decide if reporter, handler, note authors, mentions, should be
> notified
> > > > based on the change type.
> > >
> > > > + channel - code that transmits the message as an email, text
> message,
> > > > twitter, etc.
> > >
> > > > + formatter - code that formats the message into text / html / short
> > > > message,
> > > > etc. Use of templates can be useful here, where modifying the
> template can
> > > > change layout, design, show less/more fields, etc.
> > >
> >
> > > > - Support for concepts like @menitons.
> > >
> >
> > > > - Avatars should really be first class citizens across the MantisBT
> > > > experience. Similar to how that is the case with most of the
> services on
> > > > the
> > > > internet (e.g. github) or even within the companies (e.g. email
> experience
> > > > with Outlook/Exchange, Gmail, etc).
> > >
> >
> > > > - Evolve current notification preferences to allow users to provide
> more
> > > > data
> > > > like twitter account, phone number, which notifications go where,
> etc.
> > >
> >
> > > > - I would like to stage it in a way where notifications_api and html
> > > > emails
> > > > are done first, then can evolve to add other features or
> extensibility as
> > > > needed.
> > >
> >
> > > > Thoughts?
> > >
> >
> > > > Thanks,
> > >
> > > > -Victor
> > >
> >
> > > >
> ------------------------------------------------------------------------------
> > >
> > > > Rapidly troubleshoot problems before they affect your business. Most
> IT
> > >
> > > > organizations don't have a clear picture of how application
> performance
> > >
> > > > affects their revenue. With AppDynamics, you get 100% visibility
> into your
> > >
> > > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics
> > > > Pro!
> > >
> > > >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > >
> > > > _______________________________________________
> > >
> > > > mantisbt-dev mailing list
> > >
> > > > man...@li...
> > >
> > > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> > >
> >
> > >
> ------------------------------------------------------------------------------
> > > Rapidly troubleshoot problems before they affect your business. Most IT
> > > organizations don't have a clear picture of how application performance
> > > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics
> > > Pro!
> > >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > mantisbt-dev mailing list
> > > man...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> > mantisbt-dev mailing list
> > man...@li...
> > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>