Slack integration

[kaihendry]

Summary of how notifications works atm

Bugzilla

There are two typical ways that Bugzilla users emit changes:

1. Email - medium is free formatted email generated by Bugzilla
2. Pusher plugin - medium is JSON (obviously preferred)

https://github.com/bugzilla/bugzilla-bugbot for example parses bugzilla email to notify IRC users.

Example notification:

buggbot | New Bugzilla-General bug 1570013 filed by mhowell@mozilla.com.

But bugbot also allows interaction (a query), e.g.

01:11 <justdave> bug 1570013
01:11 <buggbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1570013 Bugzilla-General, normal, --, ---, general, NEW , Needinfo counter stuck at -1

Push is an extension to BMO and not shipped by default in Bugzilla stable and might have other dependencies like STOMP and by too difficult to integrate with our stable version.

MEFE (frontend)

MEFE also receives updates from Bugzilla via mysql.lambda_async triggers which causes lambda2sns to relay messages to /api/db-change-message/process. This in turn allows the frontend to send emails templated like so: https://github.com/unee-t/frontend/blob/master/imports/api/rest/post-process-db-change-message.js

Issue: However this doesn't facilitate dashboard.unee-t.com URLs. These would have to be built, if we were to use the frontend to create dashboard referencing notifications.

From the existing email templating / sending code, it's fairly straigh tfoward to add templates for a Web hook, I hope @nbiton would agree.

Slack integration

Assuming a notification to a Slack channel, without two way interaction (queries), this is straightforward to achieve via a Web hook. Some packaging is required, i.e. customer approves integration and there is some short of shared account:

• Shared account is setup with access to notifications.
• Shared account is linked to the default assignee for a given role.
• Each time a message is sent to the default assignee it shows up in slack.
• Individual user can click on the notification link.
• If Individual user has access to the unit then he/she has access to the case.
• If Individual user does NOT have access to the unit then he/she does NOT have access to the case.

Summary

Probably best not try to extend Bugzilla, and rather try support dashboard URLs via MEFE. I am not entirely sure that's possible. The use cases of how teams are supposed to interact with notifications on their Slack should be defined.

• What do teams want to see (perhaps only pictures)? Will it be actually useful / actionable?
• What do teams want to do for this stream of property information? Just a backchannel?
• Is it clear who is expected to follow up on issues? And how they are supposed to?

[franck-boullier]

Issue: However this doesn't facilitate dashboard.unee-t.com URLs. These would have to be built, if we were to use the frontend to create dashboard referencing notifications.

IMO we can ignore this issue at the moment: the notifications will include
1- links to case in the MEFE --> URL like https://case.unee-t.com/case/`case_id`
OR
2- link to the dashboard --> URL like https://dashboard.unee-t.com/show_bug.cgi?id=`case_id`

In both scenario, building the link should be trivial if we have the case_id (and we will have that case_id)

[franck-boullier]

Probably best not try to extend Bugzilla, and rather try support dashboard URLs via MEFE.

That was my assumption all along too <-- no need to do heavy customization on the BZ side and re-use what we have already built to enable the MEFE notifications.

[franck-boullier]

The use cases of how teams are supposed to interact with notifications on their Slack should be defined.

• What do teams want to see?

• To know what types of notification we need to send: see what we are currently doing with the email notification that we currently have.
• To know the content of each notification message: see what we are currently doing with the email notification that we currently have.
• To know how can you parameter what notification will be received (user preferences): see what we are currently doing with the email notification that we currently have.

• Will it be actually useful / actionable?

Yes, it will be actionable:

• The message explains what the notification is about
• The message includes a link to the case <-- the user can click on the case to know more/start working on the case.

• What do teams want to do for this stream of property information?

First a clarification:
This is not a "stream of property information", this is a stream of information about cases that are opened in a group of properties where:

• the default assignee for a given role is a "generic" user (like propertyx.help@example,com)
• this default assignee is used to configure notifications to a specific slack channel (#unee-t_notifications_sent_to_help.propertyx)

What the team wants to do:
The exact same thing as what they're currently doing with email notification when email notifications are configured for a "generic" user (like propertyx.help@example,com), only in a different channel (slack instead of email).

Is it clear who is expected to follow up on issues?

Yes it shoudl be reasonably obvious: anyone who has access to the Slack channel should know who's supposed to do what <-- this is defined by the internal workwflow of each organization/team

And how they are supposed to?

1- Click on the link to access the case
2- Assign the case either to themselves or to someone else if applicable.
3- Start working on the case if applicable

[franck-boullier]

Assuming a notification to a Slack channel, without two way interaction

This is a correct assuption

[franck-boullier]

Also for the record in Unee-T the BZ native email notification mechanism for users is disabled for all the users. We only rely on the MEFE as our notification engine ATM (and I see no reason why this should change)