Review email notification scheme

[srimanob]

Several requests to us to review notification scheme.

[justinasr]

Hi.

Currently emails are sent when:

1. There is a problem saving chained request to database after chained request validation (Body: Problem saving changes in chain ..., set validate = False ASAP!)
2. Validation fails because of wrong time per event (Body: Validation for request ... in chain ... failed) OR (Body: Validation for request ... failed)
3. Batch is announced (Subject: New ... production, batch)
4. Request joins a chain (Subject: Request ... joined chain)
5. Chained request can't flow further because of insufficient events produced (For the request ..., the completed statistics ... is not enough to fullfill)
6. Chained request flows (Body: The request ... has been flown within ...)
7. Chained request reserves requests (Body: The request ... of campaign ... has been reserved as part of ...)
8. Requests are reset in chained request when chained request validation fails (Subject: ... failed for request ...)
9. There is a problem saving chained request to database after chained request validation (Body: Problem saving changes in chain ..., set validate = False ASAP!)
10. Approval for request changes (Subject: Approval ... for ... ...)
11. Status for request changes (Subject: Status changed for request ... to ...)
12. Something fails for a request (Subject: ... failed for request ...)
13. Efficiency in validation is incorrect (Subject: Runtest for ...: efficiency is incorrect)
14. Validation ran with too little events (Subject: Runtest for ...: too few events for estimate)
15. Validation gets wrong time per event (Subject: Runtest for ...: time per event over-estimate.)
16. Validation gets too low CPU efficiency (Subject: Runtest for ...: CPU efficiency too low.)
17. Validation gets wrong size per event (Subject: Runtest for ...: size per event under-estimate.)
18. Validation gets wrong size per event (Subject: Runtest for ...: size per event over-estimate.)
19. Validation gets wrong memory (Subject: Runtest for ...: memory over-usage)
20. Batch is notified (New ... production, batch [Notification])
21. There is an error during campaign inspection (Subject: Exception while inspecting request)
22. Request leaves a chain (Subject: Request ... left chain)
23. Chained request is moved to validation (not sure about this) (Subject: Approval ... in chain ... for request)
24. Request joins a chain (Subject: Request ... joined chain)
25. Users are notified about something (Subject: Communication about request ...)
26. PWG is notified - NotifyPWG (?)
27. Config injection fails (Subject: Request injection failed for ...)
28. There is an error submitting requests to computing (Subject: Request injection happened but no request manager names for ...)
29. Request injection suceeds (Subject: Injection succeeded for ...)
30. Chain request injection suceeds (Subject: Injection succeeded for ...)

My proposal would be to remove email notifications 4, 6, 7, 10, 11, 22, 24 as they just notify about normal functions of McM and do not require any immediate attention of a user.

Justinas R.

[srimanob]

Hi Justinas,

To follow up on this, do you foresee additional development on email notification (apart from remove notification in some cases).

For example, if I touched samples, I will get notification even I left PPD.

1. Above proposal of removal email notification will help (i.e. root request is attached to the new chain).
2. Should we try to send to e-group that correspond to PWG + existing request manager, instead of person? Or implement checking if user who we will send still be GEN contact or not.

[justinasr]

Hi,

Which people are in PWG's e-group?
Two months ago I've added generator contacts (from list of McM users) of appropriate PWG to all emails sent from McM. In next MccM they were really unhappy as they started receiving emails about requests that they haven't touched (just because they were gen contact of that PWG), so I had to remove this feature. Wouldn't your second point cause same issue?
In my opinion, everyone who touched something, should receive email with an option to opt-out, which currently is implemented as blacklist. Maybe it can be moved to user list as a checkbox 'Receive emails from McM'?

[srimanob]

Or people who touch that request and still have role as GEN contact or above.
--> This will fall into issue if GEN contact quit, but something left, so no one in PWG will get email.

[justinasr]

Hm, so simple users would never get emails?

[justinasr]

After live discussion with Phat we decided that we will start by removing some of the notifications as proposed in my first message and send notifications only to people who have higher role than user.

[srimanob]

Except people who registered to the request by themselves.

[justinasr]

You're right. I'll repeat so everything will be in one place: Send notifications only to people who have higher role than user or registered to receive notifications by clicking a Register button in McM.