Loading...

Xporter

XML

Word

Printable

Details

Type: Feature
Priority: Not Assigned
Fix Version/s: PI10
Component/s: None
Labels:
- webjive

ARTs:

Obs Mgt & Controls
Benefit hypothesis:

Hide

In practice, at the moment, WebJive does not support users that want to have the same dashboard to be used for many different devices that belong to a same class.

For elements that have many similar components, the only possible solution is to manually clone a dashboard and painfully reconfigure its widgets to refer to yet another device. This is very annoying, time consuming, error prone and leading to redundancy (failing the DRY principle).

Show
In practice, at the moment, WebJive does not support users that want to have the same dashboard to be used for many different devices that belong to a same class. For elements that have many similar components, the only possible solution is to manually clone a dashboard and painfully reconfigure its widgets to refer to yet another device. This is very annoying, time consuming, error prone and leading to redundancy (failing the DRY principle).
Acceptance criteria:
Hide

~~As a dashboard designer I can:~~

~~define 1+ names of variables for a dashboard~~

~~define a domain for each of them (domain = range of possible devices, and perhaps type of device)~~

~~define a default device for each variable~~

~~names and domains are mandatory~~

when I configure a widget of the dashboard, I can use the current configuration options or I can say that the widget will listen to the device bound to the variable when the dashboard will run; in such a case I need to say what attribute or state I want to use in the widget

~~if in the domain I specified a device type then only attributes/states of that type of attributes should be selectable~~

~~the ability to choose the variable instead of a specific device is available for each widget~~

~~As a user of a running dashboard:~~

~~I can use the dashboard applied to the default device for each variable~~

~~I can select (perhaps using a combobox) a new device for each of the variables~~

~~I see 1 menu/combobox for each variable, with the name of the variable as a label~~

Revised acceptance criteria (integrating the comments below, as of Feb 22 and Mar 8):

a dashboard can have 0 (as now) or 1+ variables

there is a mechanism for configuring a dashboard and specifying a Tango device class for the variable, as well a variable name and a default device instance for the variable

the device inspector (the microwidget used in each widget to select the tango device and its attributes) is expanded to allow specification of the variable name and selection of attributes of its instances

only the attributes defined for the default device associated to the variable will be selectable in the device inspector

there is a new widget that can be used in a running dashboadr to display the variable name and a dropdown menu to select an instance of the device class associated to the variable

all widgets will be extended to cope with dashboard variables

when importing a dashboard, Taranta checks that the device class and default device exist, and if not warns the user and provides whatever info is needed and possible for the user to amend the dashboard if s/he wants to.

What will not be done is:

the parametric dashboard will not handle dynamic attributes not defined for the default device

providing a way to the dashboard designer to enumerate the devices the dashboard variable can refer to.
Show
As a dashboard designer I can: define 1+ names of variables for a dashboard define a domain for each of them (domain = range of possible devices, and perhaps type of device) define a default device for each variable names and domains are mandatory when I configure a widget of the dashboard, I can use the current configuration options or I can say that the widget will listen to the device bound to the variable when the dashboard will run; in such a case I need to say what attribute or state I want to use in the widget if in the domain I specified a device type then only attributes/states of that type of attributes should be selectable the ability to choose the variable instead of a specific device is available for each widget As a user of a running dashboard: I can use the dashboard applied to the default device for each variable I can select (perhaps using a combobox) a new device for each of the variables I see 1 menu/combobox for each variable, with the name of the variable as a label Revised acceptance criteria (integrating the comments below, as of Feb 22 and Mar 8): a dashboard can have 0 (as now) or 1+ variables there is a mechanism for configuring a dashboard and specifying a Tango device class for the variable, as well a variable name and a default device instance for the variable the device inspector (the microwidget used in each widget to select the tango device and its attributes) is expanded to allow specification of the variable name and selection of attributes of its instances only the attributes defined for the default device associated to the variable will be selectable in the device inspector there is a new widget that can be used in a running dashboadr to display the variable name and a dropdown menu to select an instance of the device class associated to the variable all widgets will be extended to cope with dashboard variables when importing a dashboard, Taranta checks that the device class and default device exist, and if not warns the user and provides whatever info is needed and possible for the user to amend the dashboard if s/he wants to. What will not be done is: the parametric dashboard will not handle dynamic attributes not defined for the default device providing a way to the dashboard designer to enumerate the devices the dashboard variable can refer to.
Feature Points:
4
Initial Size:
5
WSJF:
6.5
Epic Link:
Taranta Tool Development
Agile Teams:

Team_CREAM
Due Sprint:
Sprint 5
Story Point Burn-up:
Overdue:
Outcomes:

Hide

Code is revised and merged by MAXIV https://gitlab.com/MaxIV/webjive/-/commit/251ba0aea26187d3cf3975f0f3af1401f2f81083
New charts are released and available on nexus, Webjive:1.0.21 and Webjive-dashboards:0.1.4.
Docs tests and coverage are in place

Show
Code is revised and merged by MAXIV https://gitlab.com/MaxIV/webjive/-/commit/251ba0aea26187d3cf3975f0f3af1401f2f81083 New charts are released and available on nexus, Webjive:1.0.21 and Webjive-dashboards:0.1.4. Docs tests and coverage are in place
Resolved PI.Sprint:
10.6

Feature Checklist:

Stories Completed, Integrated, Demonstrated, Satisfies Acceptance Criteria, Accepted by FO

Demos:
- OMC_ART_SystemDemo_3
Requirement Status:

PI22 - UNCOVERED
Labels_MIRO:
webjive

Description

In some of the elements we will have sets of devices that are similar (like the VCCs in the CSP). Uses are likely to have to build dashboards to monitor each of such a set of devices.

Right now, the only way to do it is by manually copy a dashboard and reconfigure its widgets so that they refer to another instance of the devices in the set.

A better solution would be through “parametric” dashboards.

A dashboard configuration would require definition of one or more “device variables”; each variable is a name whose values would range on a set of devices that belong to the same class. There is also a default device to use for each variable.

Once a variable is defined for the dashboard, then its widgets could refer to the variable device instead of the actual device.

When running such a parametric dashboard, the device variables would get as a value the default device. But the user would be able to see and access a dropdown menu from which to select another device of the class, and the dashboard would be re-rendered with attributes and states deriving from that device.

If there are 2+ variables, then there will be 2+ dropdown menus. (This is the way in which Grafana provides parametric dashboards).

See the attachments for possible examples of how a widget that refers to a variable device might look like, and how variables are defined in Grafana.