Expand Alarm Configuration Actions

[shroffk]

Checklist

• Testing:

  • The feature has automated tests
  • Tests were run
  • If not, explain how you tested your changes

• Documentation:

  • The feature is documented
  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant
    • Added an entry when adding a new feature

[shroffk]

[kasemir]

Is there a way to suppress the context menu? Maybe that's already in the contribution support, I forgot. Or somehow tie this to authorization for the alarm configuration?

In any case, for our setup I don't want to have "Add to alarm tree" in every PV context menu.
Adding an alarm requires some thought. Authorization is limited to those who check if the PV is useful, what the guidance should be, suitable related display etc.

[shroffk]

I can add a preference for this, the framework already exists in the ContextMenuAction interface

While I agree that alarm configurations should be made thoughtfully... this context menu is just making the current "add component" action from the alarm tree, which does allow specifying multiple PVs, a little bit easier to access.

[shroffk]

by simplifying this workflow I am hoping to avoid other programmatic/scripted solutions which have been necessary when adding a large number of PV's...a workflow which is even future away from the thoughtful user actions :)

The authorization part is a valid issue which might need a bit more thought

[georgweiss]

I'm quite sure authorization and authentication is needed for ESS to put this to use. My users have already expressed a requirement to limit access to the menu item to remove nodes. I would be happy to contribute.

As for the context menu: in save&restore access to certain actions requires an authenticated session. Maybe such a scheme could be used to hide the context menu.

[georgweiss]

I do like fxml (the new add dialog), but I guess that ideally the alarm tree UI should then also be fxml...