ISIS alarm improvement work #3995

Following up on the discussions during the monthly meetings and the Codeathon, I have created a more precise list of work I want to do on the alarm system over the next few months.

Thought it best to create a issue so that the alarm work I'm planning is written down somewhere (please let me know if you'd prefer this split up into multiple issues).

I'm not 100% sure on how every work item should be implemented and whether any will cause problems for other facilities, so please let me know any thoughts or if anyone is interested in helping, discussion is very welcome and this issue will likely evolve.

Context

I am an industrial placement student (i.e. senior intern™) working at ISIS Neutron and Muon source until August, focused on alarms.

We are migrating from an old control system (Vista) to EPICS. As part of this work, we are migrating and improving our alarm system. Over the last 2 months I have talked with our control room crew and head of operations to find out the current issues with the alarm system, prototyped some solutions, and gathered feedback and iterated on them. I have discussed most of these work items at the monthly meetings and was present for the alarm discussion at the Codeathon.

Alarm configuration improvements

• (Add editing mode to alarm tree #3991) Add 'editing mode' to alarm tree as discussed in Codeathon
• Remove configuration dialog box and embed alarm configuration options into a panel on the right side of the alarm tree
  • Panel hidden when not in editing mode
  • Have to click 'save changes' or similar for changes to be sent to Kafka
• Alarm configuration table improvements
  • Improve UI for tables by allowing drag/drop, copy/paste, adding keybinds, potentially adding a context menu - not 100% sure what this will involve yet
• Clientside checking for enabling filter
  • Syntax checking to make sure the expression 'compiles'
  • Live checking of whether the expression evaluates to true or false
  • Have not looked into this at all yet - may be technically impractical
• Drag and drop
  • Allow selected alarms/components to be dragged and dropped
• Copy/cut/paste
  • Allow selected alarms/components to be copied/cut/pasted with buttons in the context menu
  • Remove 'move item' after both this and drag/drop are implemented
• Remove 'rename item' and allow the item to be renames in the configuration menu

Prototype:

General alarm tree improvements

• (Alarm tree search #3988) Add PV search bar to alarm tree
• Replace alarm tree expand buttons with filter
  • Remove the 'expand to show [active|disabled] alarms' buttons and replace them with a dropdown containing tri-state checkboxes: 'Active alarms', 'Disabled alarms', 'Acknowledged alarms' (is this too convoluted?)
  • This may break workflows, but a filter seems like it would be a more intuitive and useful way to interact with the alarm tree, and having both options seems like a confusing middle ground (any thoughts?)
  • It would be useful to be able to automatically expand nodes to see the leafs when a filter is active, but this would not work well if you set it to e.g. all inactive alarms. Not sure how to handle this yet
• Alarm tree context menu improvements
  • Collapse guidances into 'N guidances...' if the number of guidances exceeds a threshold, rather than truncating them
  • Collapse screens into 'N screens...' if the number of screens exceeds a threshold, rather than truncating them
  • Change 'Remove selected items' to 'Remove [N] items', and the same for enable/disable (counts components and their children)

Alarm disable improvements

• Alarm disabling UI improvements
  • Merge 'disable indefinitely' and 'disable until' options into one single dialog box
  • Box lists all PVs/components to be disabled and the number of alarms to be disabled at the top
  • Box would have a radio selection with options 'Indefinitely', 'Custom', and a set of predefined times from settings
  • Predefined times can be relative (5 minutes, 1 century) or absolute (15:00, Monday 16:50) (why absolute? may want to disable alarm until next shift, end of cycle, or similar - addresses common periodic events)
• Alarm disable reasons
  • Add a 'Disable reason' radio selection to the alarm disable dialog box containing a set of predefined reasons from settings, or 'custom'
  • To make this a non-breaking change, reasons can be null - but add an option to settings.ini to require operators to add a reason
  • Change alarm tree to display disabled reason alongside 'Disabled'
  • Change config dialog box to display disabled reason next to 'Enabled' (enabled checkbox will need to be moved)

Prototype: