Will Kahn-Greene [:willkg] ET needinfo? me Assignee
	Description • 9 years ago

We're creating a new Alerts backend on Input that will drive Input alerts going forward. This backend will be housed in its own Django app much like the Heartbeat backend.

After discussions with Robert and Cheng (who are the initial primary users of the Alerts backend), the schema should look something like this:

Every alert instance has a:

* unique id
* created timestamp
* alert type - which lets us distinguish categories of alerts
* severity
* description/text - that summarizes the circumstances that triggered the alert
a set of links like the input response, bug, github commit, etc of things associated with the alert and places to go for more information
* links to more information
* emitter name
* emitter version

Every alert type has a:

* unique id
* name
* description - which includes information about the source of alerts of this type
* more_info_link - which we can use in places that display alerts allowing users viewing the alerts to go somewhere to view more information about that alert
* default_severity??
* enabled flag - indicating whether alerts can be posted for that type


This bug covers fleshing out the schema to something that meets requirements in the project plan and then implementing the app, models and model factories.

	Will Kahn-Greene [:willkg] ET needinfo? me Assignee
	Comment 1 • 9 years ago

I spent some time thinking about the schema and made some changes from what I specified in the description.

In a PR: https://github.com/mozilla/fjord/pull/489

	Will Kahn-Greene [:willkg] ET needinfo? me Assignee
	Comment 2 • 9 years ago

Landed in master: https://github.com/mozilla/fjord/commit/0fa0aabc6c2267f7ed76b237cb79d09fe9ae434f

Waiting to push this out until tomorrow.

	Will Kahn-Greene [:willkg] ET needinfo? me Assignee
	Comment 3 • 9 years ago

Pushed this to production. Without the API bit (bug #1130765) it doesn't do much.

Marking as FIXED.