GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2018-09-21T19:22:21Zhttps://git.ligo.org/computing/gracedb/server/-/issues/15Rework permissions structure2018-09-21T19:22:21ZTanner PrestegardRework permissions structureWe need to define a permissions structure for controlling superevent actions, as well as upgrade the old one for events. Here is a proposal for how to define this structure going forward.
**Update** (6 Sept 2018): this issue is no long...We need to define a permissions structure for controlling superevent actions, as well as upgrade the old one for events. Here is a proposal for how to define this structure going forward.
**Update** (6 Sept 2018): this issue is no longer going to cover redoing the events permission structure; it will only focus on creating the superevents permission structure.
# Creation
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| create event | Specific LVK users only | Currently allowed for pipeline accounts and specific users; remove individual users? |
| create test event | All LVK users | |
| create superevent | emfollow/superevent manager | |
| create test superevent | All LVK users | |
| create MDC superevent | emfollow/superevent manager | |
# Updates
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| update/replace event | Only the user who originally submitted the event | Or should it be anyone who is allowed to submit events for the given pipeline? |
| update/replace test event | All LVK users | |
| update superevent | emfollow/superevent manager | Applies to production and MDC superevents |
| update test superevent | All LVK users | |
| add/remove event from superevent | emfollow/superevent manager | Production and MDC |
| add/remove event from test superevent | All LVK users | |
| confirm superevent as gw | Some special people | Should emfollow/superevent manager be on this list? |
| confirm test superevent as gw | All LVK members | |
| confirm mdc superevent as gw | emfollow/superevent manager | |
# Annotations
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| add log message/file | All LVK (all events/superevents); LV-EM (only exposed events/superevents) | Not allowed for public users (?) |
| tag log message/file | All LVK (all event/superevent logs) | Not allowed for LV-EM or public |
| untag log message/file | All LVK (all event/superevent logs) | Not allowed for LV-EM or public |
| add label | Specific LVK members can add specific labels | Needs some thought and a finalized list of labels to define this |
| remove label | Specific LVK members can remove the same specific labels | |
| create voevent | emfollow | Are others needed? |
| create emobservation | All LVK (all events/superevents) and all LV-EM (all exposed events/superevents) | This is a little weird because as far as I know, only LV-EM people should be uploading EM observations |
| add/update/remove operator signoff | LVK members in control rooms | Control room groups controlled by IP address |
| add/update/remove advocate signoff | LVK members in em_advocates group | |
# Viewing
| Action | Allowed users | Comments |
| ------ | ------------- | -------- |
| view event | All LVK (all events/superevents); LV-EM/Public (exposed events/superevents? Or just superevents?) | Applies equally to production and test events. Note to self: need to consider event subtypes and permissions on those as well |
| view logs | All LVK (all event/superevent logs); LV-EM/Public (exposed logs only) | Logs will be exposed via a tag ('lv-em' or 'public'); files associated with exposed logs will also be exposed | |
| view voevents | All LVK (all voevents); not sure about LV-EM or public | Currently, all VOEvents are viewable to anyone who can view the event|
| view emobservations | All LVK (all emobservations); not sure about LV-EM or public | Currently, all EMObservations are viewable to anyone who can view the event |
# Main questions
1. Who can add/remove which labels? Or should all LVK users be able to add/remove all labels?
2. Who can expose/hide events and superevents?
3. Who can expose/hide logs with the 'lv-em' and 'public' tags?
4. Does exposing a superevent to external users mean that we should expose all of the individual events as well?
5. Who can confirm superevents as GWs?Move superevents branch onto production GraceDBhttps://git.ligo.org/computing/gracedb/server/-/issues/8Reworking LVAlert types and contents2018-09-21T19:18:37ZTanner PrestegardReworking LVAlert types and contentsThere is a need to add more finely divided categories for LVAlerts and possibly change the type of serialized objects which are included with them. Should more/different information be added as well?
# Current status
## Contents of al...There is a need to add more finely divided categories for LVAlerts and possibly change the type of serialized objects which are included with them. Should more/different information be added as well?
# Current status
## Contents of alert JSON packet
Currently, LVAlert JSON packets include the following keys:
* object: dict representation of a database row; typically an event, superevent, or log object. Note that these should be identical to the representation of these object available from the API.
* description: text description of the action which triggered the alert
* uid: event graceid or superevent id
* alert_type: either "new", "label", "update", or "signoff"
* labels: list of label names attached to the event or superevent
* file: filename string (optional and relative)
## Actions for which GraceDB issues alerts
GraceDB issues LVAlerts when the following actions are taken:
### Events
Constants:
* uid: always the related event's graceid
* labels: always a list of the related event's labels
| Action | alert_type | object | file | description |
| ------ | ---------- | ------ | ---- | ----------- |
| Event creation | "new" | event | Link to initial event file | "" |
| Event log creation (no file) | "update" | log | "" | "LOG: comment" |
| Event log creation (with file) | "update" | log | filename | "UPLOAD: 'filename' comment" |
| Label added to event | "label" | Not included in dict | "" | H1OK |
| Label removed from event | "update" | Not included in dict | "" | "Label H1OK removed" |
| VOEvent created for event | "update" | voevent | G0001-3-Update.xml | "VOEVENT: G0001-3-Update.xml" |
| EM observation created for event | "update" | emobservation | "" | "New EMBB observation record." |
| EMBB event log created for event | "update" | embb event log | "" | "New EMBB event log entry." |
| Event added to superevent | "update" | log | "" | "LOG: Added to superevent S180614b" |
| Event removed from superevent | "update" | log | "" | "LOG: Removed from superevent S180614b" |
| Event selected as preferred event for superevent | "update" | log | "" | "LOG: Set as preferred event for superevent: S180614b" |
| Event removed as preferred event for superevent | "update" | log | "" | "LOG: Removed a preferred event for superevent: S180614b" |
| Operator or advocate signoff (initial or update) on event | "signoff" | signoff | "" | "OK" or "NO" |
### Superevents
Constants:
* uid: always the related superevent's superevent_id
* labels: always a list of the related superevent's labels
| Action | alert_type | object | file | description |
| ------ | ---------- | ------ | ---- | ----------- |
| Superevent creation | "new" | superevent | "" | "NEW: superevent S180614a" |
| Superevent update (preferred event, t_start, t_0, t_end) | "update" | log | "" | "LOG: Updated superevent parameters: t_0: 1 -> 2, preferred_event: G0001 -> G0002" |
| Log creation (no file) | "update" | log | "" | "LOG: comment" |
| Log creation (with file) | "update" | log | filename | "UPLOAD: 'filename' comment" |
| Event added to superevent | "update" | log | "" | "LOG: Added event: G0001" |
| Event removed from superevent | "update" | log | "" | "LOG: Removed event: G0001" |
| Label added to superevent | "label" | Not included in dict | "" | "LABEL: H1OK" |
| Label removed from superevent | "update" | Not included in dict | "" | "UPDATE: H1OK removed" |
| Confirm superevent as GW | "update" | log | "" | LOG: Confirmed as a gravitational wave." |
| Create VOEvent for superevent | "update" | voevent | S180614b-3-Update.xml | "VOEVENT: S180614b-3-Update.xml" |
| Create EMObservation for superevent | "update" | emobservation | "" | "New EMBB observation record for DESGW." |
| Operator or advocate signoff (initial or update) on superevent | "signoff" | signoff | "" | "OK" or "NO" |
| Operator or advocate signoff deleted | "update" | log | "" | "LOG: operator signoff for H1 deleted: H1OK removed and H1OPS reapplied" |
Note that there are no EMBB event logs for superevents since they seem to have fallen out of use (there were only ever 31 of them created and the last one was applied for events in ~2015).
## Actions for which GraceDB does not issue alerts
LVAlerts are *not* issued when the following actions occur:
* Event created with labels attached ("new" alert goes out but no "label" alert; this probably should happen)
* Note that superevents created with labels first issue "new" alerts and then "label" alerts
* Event "replaced" with new event file (should probably send an "update" alert)
* An event signoff is deleted.
* An event log or superevent log has a tag applied or removed (I don't think anyone wants to get this alert)
* A log message is generated to document the above action (I don't think anyone wants to get this alert)
# Development action items
We want to do the following:
* Define some new alert_type categories and what actions they should be used for.
* Add alerts for some of the actions listed above.
* Change what type of serialized object is included with certain alerts
* Add documentation of alert contents and actions which trigger them
We might want to:
* Add entirely new information to alerts (i.e., new dict key(s) and value(s))Readiness for second OPA testhttps://git.ligo.org/computing/gracedb/server/-/issues/73Access, authorization, and permissions2019-03-04T19:36:00ZTanner PrestegardAccess, authorization, and permissionsThis issue will be used to track ongoing questions about how to manage the following things in GraceDB:
* External (LV-EM and public) access
* Information shown to external users
* Permissions assigned to usersThis issue will be used to track ongoing questions about how to manage the following things in GraceDB:
* External (LV-EM and public) access
* Information shown to external users
* Permissions assigned to usershttps://git.ligo.org/computing/gracedb/server/-/issues/72Policy for alerts2018-10-05T17:01:56ZTanner PrestegardPolicy for alertsWe should define a policy for alerts and post it at least on a page on GraceDB, possibly in the DCC as well. The main questions to be answered by this policy are:
1. Should any alerts (phone, email, LVAlert) be sent out outside of obse...We should define a policy for alerts and post it at least on a page on GraceDB, possibly in the DCC as well. The main questions to be answered by this policy are:
1. Should any alerts (phone, email, LVAlert) be sent out outside of observing runs?
2. How should we handle existing alerts when beginning a new observing run?
There is potential for an issue to occur due to people leaving the collaboration, but still having alerts set up. But as long as the LDAP is kept up-to-date, that shouldn't be a problem, since we already have a nightly cron job which deletes all Contacts and Triggers for users who are no longer in the LVC.https://git.ligo.org/computing/gracedb/server/-/issues/2Superevent queries2022-09-12T10:34:28ZTanner PrestegardSuperevent queriesThis issue is created to get some feedback on what attributes would be most useful for querying for superevents, as well as which attributes should be added to event queries. Here's what I came up with off the top of my head.
### Super...This issue is created to get some feedback on what attributes would be most useful for querying for superevents, as well as which attributes should be added to event queries. Here's what I came up with off the top of my head.
### Superevents
* Search by superevent ID (date-based)
* Superevent submitter
* Ranges of `t_start`, `t_0`, `t_end` (GPS times)
* Whether an alert has been sent out for the superevent
* Whether the superevent is confirmed as a GW
* Preferred event graceid (possibly a range of graceids)
* Event graceids
* Labels
* Do we need the ability to find superevents based on attributes of their preferred events? Ex: find all superevents with a preferred event which was identified by the CWB pipeline. If this seems useful, which attributes?
### Events
* Find all events which are preferred events for superevents
* Find all events which are part of a particular superevent
* Find all events which are part of any superevent (or are NOT part of any superevent)
If there are other filters which would be useful, or if any of these don't seem useful, please comment!