GraceDB Server issueshttps://git.ligo.org/computing/gracedb/server/-/issues2022-08-03T19:03:05Zhttps://git.ligo.org/computing/gracedb/server/-/issues/82Bad encoding of file download URLs2022-08-03T19:03:05ZTanner PrestegardBad encoding of file download URLsLinks on event detail pages (in the log messages) (probably for superevents, too) with special characters in them like '#' don't work properly. They are OK on the event file list page (probably because the `url` template tag encodes the...Links on event detail pages (in the log messages) (probably for superevents, too) with special characters in them like '#' don't work properly. They are OK on the event file list page (probably because the `url` template tag encodes them properly).
We can use probably use `encodeURLComponent()` in Javascript to fix the issue in the log messages. We should check on the file lists for superevents too. And we will have to patch the client to encode the URL properly in the `files()` method.https://git.ligo.org/computing/gracedb/server/-/issues/41Event page date/time selection2022-08-03T18:38:45ZTanner PrestegardEvent page date/time selectionCreated by Stephen Privitera on August 25, 2015. Copied from redmine (https://bugs.ligo.org/redmine/issues/2419)
This is just a design suggestion. There should be one and only one place where the date format can be chosen (i.e. GPS vs. ...Created by Stephen Privitera on August 25, 2015. Copied from redmine (https://bugs.ligo.org/redmine/issues/2419)
This is just a design suggestion. There should be one and only one place where the date format can be chosen (i.e. GPS vs. LLO time vs. UTC ...). At the moment, the default display for me is GPS in the "Basic Info" and LLO local time everywhere else. It would be nice if by default these were the same, and if I decide I don't like whatever the default display is, saying so in once should be enough!https://git.ligo.org/computing/gracedb/server/-/issues/71Rework labels2019-01-31T16:27:59ZTanner PrestegardRework labelsThere is a desire to add several new labels and remove some of the old ones. Will we completely remove some of them? Should some of them remain in place for historical purposes, but be prevented from being added in the future? Unclear...There is a desire to add several new labels and remove some of the old ones. Will we completely remove some of them? Should some of them remain in place for historical purposes, but be prevented from being added in the future? Unclear.
This issue is developing and being documented in the following Google Sheet: https://docs.google.com/spreadsheets/d/1E5LHIZDW9gEZZpUa-BsyfW7W62SGNbtk-ej4FDDwwyA/edit#gid=0Readiness for second OPA testhttps://git.ligo.org/computing/gracedb/server/-/issues/94Update superevent pages2018-11-30T17:20:16ZTanner PrestegardUpdate superevent pagesWe need to make some changes to what information is shown on various pages (search results, superevent detail page, etc.), both for authenticated users and for public users. We also need to make changes for how superevents are serialize...We need to make some changes to what information is shown on various pages (search results, superevent detail page, etc.), both for authenticated users and for public users. We also need to make changes for how superevents are serialized for public users. Probably want to make a new serializer and select based on user authentication status.
More information to come.Public-facing GraceDBhttps://git.ligo.org/computing/gracedb/server/-/issues/70Critical unit tests2018-09-25T15:13:14ZTanner PrestegardCritical unit testsWe need unit tests for checking permissions for superevents. We have to check all API "actions", views, etc. and all web views.We need unit tests for checking permissions for superevents. We have to check all API "actions", views, etc. and all web views.Move superevents branch onto production GraceDBhttps://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 GraceDB