Open kaihendry opened 5 years ago
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
)
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.
The use cases of how teams are supposed to interact with notifications on their Slack should be defined.
- What do teams want to see?
- Will it be actually useful / actionable?
Yes, it will be actionable:
- 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:
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
Assuming a notification to a Slack channel, without two way interaction
This is a correct assuption
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)
Summary of how notifications works atm
Bugzilla
There are two typical ways that Bugzilla users emit changes:
https://github.com/bugzilla/bugzilla-bugbot for example parses bugzilla email to notify IRC users.
Example notification:
But bugbot also allows interaction (a query), e.g.
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:
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.