Alarm/OPI interaction. PVs to display & ack’ alarms (Lead: Nadine - Reviewers: Eric)

[berryma4]

I have an awful version I use for one opi screen:
https://stash.nscl.msu.edu/projects/CF/repos/org.csstudio.pvmanager.jms.beast.feature/browse

[kasemir]

Notes from discussion at today's hangout..

Simpler TO-DO Items:

1. Core plugin for alarm colors (foreground, background) and icons to represent the alarm severities. Then use that in alarm plugins, opibuilder, any other place that wants to render alarms.

2. Alarm Table columns: Configure via preferences similar to message log history.
   Replace with JavaFX Table? Would allow easy runtime changes to columns, may overall be a better table. But note that this change is primarily about configuring the columns once, and operators shouldn't need to (be able to?) change them at runtime.

3. Default 'double-click' action for Alarm Table.
   .. mostly to open one designated related display.

Alarm PVs: PV for alarm ack, table PV for current alarms, …
This once looked like a great building block.
If the Alarm Table etc. don't work for you, create your own *.opi that talks to the alarm server.
--> Impossible?
Based on Eric's trials, no good fit for 'PV'. How to support alarm-specific context menus?

Alarm filtering:
Provide a 'Contextual' Alarm Table that uses E4 'Context' Variable for current alarm hierarchy level.
Set by Alarm Tree, or set by BOY Script, or set by new ITER navigational widget that updates linking containers, ...
Alarm Table only shows alarms below that level. Its tab name reflects the currently active alarm hierarchy level. Has option to show 'all', ignoring the alarm level context variable.

Not 100% if E4 context variable is the best mechanism, but looks like it at this time.
The Lars Vogel article http://www.vogella.com/articles/Eclipse4Services/article.html lists E4 communication mechanisms.
In E3, there was mostly the ISelectionProvider, one global selection mechanism.
If you want to pass updates on various model items between E4 components, you can use context variables.
Publishing anything into a context variable is as easy as publishing a selection, but note that you can now name the item that you put into the context. This allows you to publish different types of information under different names, effectively having access to multiple selection services.
You can either use a string or a class reference:

@Inject
public void methodThatPublishesContextVariable(final MWindow window)
{
    final IEclipseContext context = window.getContext();
    context.declareModifiable("alarm_level");
    context.set("alarm_level", "/The/Current/Alarm/Level");
}

Receiving the item updates is easy in E4 when you have injection support:

// E4 will invoke this whenever the named context variable changes.
@Inject
public void handleChangedAlarmLevel(
    @Optional
    @Named("alarm_level")
    final String level)
{
    System.out.println("Should filter alarms to level " + level);
}

Not sure how this would work with the compatibility layer, might need to somehow get the MWindow, then window.getContext() .. as done in other code that was adapted to E4.

[utzeln]

Let's start with adding a column for the alarm priority icon - by default, this column will be hidden.

Proposal for the icons:

[utzeln]

ITER requires also that to the left of each alarm there shall be an acknowledgement tick box. By default this column will be hidden.

[utzeln]

Regarding the requirement to have the alarm table layout configurable.

Preferences should allow to specify if a column is shown or hidden, to order the columns up and down, and to change the column properties such as the name of the column and its width.

To be confirmed if the weight of the column has also to be taken into account as it is in the message history.

The preference GUI could be based on the problems view “Configure Columns…” interface:

[utzeln]

The alarm table layout for ITER shall include the alarm action and alarm ID. Using the first guidance title for the alarm ID and its details to describe the action, could do it. But this means that 2 additional columns are required - hidden by default.

[kasemir]

Regarding your icon proposal, using the basic Eclipse 'error' and 'warning' icons for major & minor alarms sounds reasonable.

I really like the added checked box for the 'acknowledged' version, especially when you add checkboxes for yet another way to acknowledge alarms. At the same time, I would then assert that icons which indicate acknowledged alarms are not confused with actual check boxes.
So instead of acknowledged alarm icon == full size check box with small 'error' decoration, maybe do it the other way around: acknowledged alarm icon == full size 'error' icon with check box decoration. That way, it's obvious that the check box is a decoration, and not a clickable check box.

I don't understand the icons for alarms cleared but not acknowledged.
Is that an "I" with decoration?
Again I'd base those on the full size error resp. warning icons but with decorations that indicate that the PV is again OK. Simplest case, add "OK" as a decoration. Or a green check mark.
So overall, more like this, where the main icon (error, warning, ..) stays similar but the decorations reflect acknowledged or recovered state detail:

Finally, what about invalid and undefined alarms?
Could use something that indicates 'unplugged', like a version of the 'plug' icon that indicates that a PV is not fully 'plugged in', u.e. disconnected:

[utzeln]

The "i" stands for Information - i.e. there was a problem, but now it's OK.

OK for having always the full size error and warning icons and adding decoration for checked/acknowledged and Information.

Good point regarding Invalid and undefined alarms. Icons are fine for me :).

[utzeln]

Updated icons:

[utzeln]

To be discussed:
“Group By” option for acknowledged/un-acknowledged alarms: if false, all the alarms are displayed in the same table; if true (by default), alarms are displayed as of today in 2 parts - current alarms and acknowledged ones.

[kasemir]

The icons are good!
Note that EPICS used to have no alarm, minor, major, invalid, but V4 and the alarm system now support no alarm, minor, major, invalid, unknown. For icons, I think it's OK to treat invalid and unknown as the same.
You'll also need an icon for invalid(==unknown) + cleared-but-unacknowledged and invalid(==unknown) + acknowledged. Could use the same (i) resp. checkmark overlay as minor and major icons.

Regarding "Group By":

Yes, this needs to be an option so that the original behavior where acknowledged alarms move to the bottom remains available.

When you select the new behavior that places all alarms, ack'ed or not, in one list, are they simply sorted by their org.csstudio.alarm.beast.SeverityLevel, as long as the user selects the severity column as the sorting criteria? Or do you want to sort them by selected column, plus another hidden sorting criteria based on ack'ed or unack'ed?

[jbobnar]

I assume the icons should be stored into a "common" plugin that also defines all the alarm colors etc. Are there any preferences on what that plugin should be called and where I should put it? How about "core/ui/ui-plugins/org.csstudio.ui.resources"?

[utzeln]

Summary of our last discussion regarding Icons:

When “Group By” acknowledged/un-acknowledged is set to false, then all alarms are shown in the same table. A “Sort By” option should also allow to specify which column is used to sort the alarms and if it is ascending order or not. And the setting can be changed at runtime by clicking on the header of the column.

For ITER, the sorting criteria will be based on the alarm level to list alarms in the following order:

1. Invalid / Unknown alarm
2. Major unacknowledged alarm
3. Minor unacknowledged alarm
4. Alarm cleared but unacknowledged - invalid, then major, then minor
5. Acknowledged alarm - invalid, then major, then minor.

Where there is more than one Invalid/Unknown, Major or Minor alarm (acknowledged or unacknowledged) these shall be ordered by time i.e. most recent at the top of the list. So this means that we have a main column "sorting by", and the second criteria - time - could be by default / hidden
(i.e. not a user selection).