Draft: allow for preferred events by pipeline
Described in words in this issue: #216 (closed)
The basic steps are:
-
create database table with basic validation -
create path through API to add and remove events (i'm thinking that i just add them to the same as for modifying superevents, to combine API calls) -
create a validator or form that ingests a superevent_id
and agraceid
and then adds or removes the event from the table -
add the table to the rest API and igwn_alert
response -
add log messages and igwn_alerts for new additions. I think that should come for free with the modify superevent API route. -
make a table on the superevent landing page -
unit tests and whatnot
I'm insistent on having GraceDB be "dumb" in terms of choosing which events are preferred by pipeline. But, GraceDB should have some logic about what events can and can't be in the table. My first cut at the logic is:
- elements in the
pipeline_preferred
table are unique based on their pipeline. so only one addition per pipeline. - a superevent's
preferred_event
is always in thepipeline_preferred
table. Changing thepreferred_event
will add or remove events from thepipeline_preferred
table, provided that the uniqueness constraint is maintained. The newpreferred_event
is given priority in the - Adding a new pipeline_preferred event to the table, where there is an existing event from the same pipeline removes the old event in favor of the new one. So new pipeline preferred events take priority.
- Removing pipeline preferred events from the table is allowed, but not in the event is current the
preferred_event
.
Edited by Alexander Pace