Notification Subscription - Field Driven Updates

* Original + Attribution:

Send notification emails (to those subscribed) when specific inputs on the form receive specific values.

This is a follow-up to PROD-114 solving the problem in a more elegant way and opening the door to greater user satisfaction in ways no other solution can accomplish. Priority is low from a relative standpoint - this is an update of choice not need, a "nice to have".

What problem are we solving?

We only want to be notified when particular values are entered, regardless of form state. It matters less if the form has just been created or updated or closed, and more that someone entered a particular value which should trigger other business processes. An email notifying subscribers of that event could kick off those processes.

Who are we solving it for?

All users, but in particular project team members who need to take external action (outside of mercury) when particular information is entered into mercury.

What should happen?

Administrators who create templates should be able to add a list of "Notification Events" to the template (stored in the template data structure as a new field). A notification event should have a name and brief description which will be shown, once the template is published and imported to projects, to any users in a modal list on the template home page allowing them to pick one or many to subscribe to. The template author creating the notification even will be able to pick particular inputs or combinations of inputs from the template and particular values for those inputs that, when satisfied, trigger the email notification to subscribers. The author should also be able to enter some boilerplate text saved with the Notification Event definition that gets included in the body of the outgoing email. The actual mechanism for the trigger will be a check within the api endpoint that handles form updates (ie: someone clicked the "save" button on a published form, and yes it should be only applicable to published forms not draft) which runs through the template definitions to see if any matching conditions have been met. It will need the previous form value as well to determine if the update created the matching condition or if it pre-existed (notifications should only go out for the update that causes the condition to be met).

Users should have a "subscribed notifications" page in their profile that lists all Notification Events they have subscribed to across all projects, and allows them to manage those subscriptions.

How will we know it’s done?

The features above are implemented in a testable (both automated and human) way.

Article(s) to Publish

notes / constraints: