Project

General

Profile

Bug #4746

ability to create a Site Layout report

Added by Daniel Crawl over 9 years ago. Updated about 7 years ago.

Status:
In Progress
Priority:
Normal
Category:
sensor-view
Target version:
Start date:
02/05/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4746

Description

Save all the information in an engineering view site as single, printable document.


Related issues

Blocks Kepler - Bug #4741: create icons for engineering view componentsNew02/05/2010

Blocks Kepler - Bug #4750: create wiring table guiNew02/05/2010

History

#1 Updated by Daniel Crawl about 9 years ago

The current reporting system lets the user create a report template, which gets filled in with values generated by workflow execution. (Does it also allow static values such as parameter values to be filled in)?

For this bug, the site layout report contains only static documentation, e.g., all the sensors in a site layout including their type, model, sampling rate, etc.

Also, instead of starting with an empty report template, it'd be nice to start with a "meta-template" that contained all the documentation/metadata about a site and let the user remove anything they didn't want.

#2 Updated by Derik Barseghian almost 9 years ago

Do some UI mockups this type of specialized report associated w/ the site layout. By default a Site Layout report design could be filled in with useful info from the site, but could be specialized in the typical way by dragging and dropping, etc. New type of report item(s) will need to be created.

#3 Updated by Derik Barseghian over 8 years ago

changing bugs from REAP to Kepler product

#4 Updated by Derik Barseghian over 8 years ago

Dan and I just brainstormed on this. A few possible solutions:
1) On the original idea of using Reporting, a few obstacles:
  • We've changed things such that the Reporting view no longer shows up when you're dealing with a site layout, only the Sensor Site and Plot Designer views.
  • Provenance turns off for DE workflows, like site layouts, so that a user monitoring a site isn't recording a bunch of data to their provenance store. Reporting gets its values from provenance, so we'd have to add the capability to get current parameter values from the workflow instead.
  • We'd also probably want to implement the report template idea Dan mentions above, as otherwise creating a thorough site snapshot report will be confusing and tedious.
    2) An alternate idea is a new Print option in Kepler. The idea is to print out a text form of the workflow that's more readable than the xml, but that also shows useful e.g. parameter information.
    3) Another idea is adding the ability to toggle showing parameter info beneath each actor. We could then leverage the existing Print functionality. This provides more context than #2, but doing layout, e.g. such that text does not overlap other actors, would be a hurdle.

We're currently leaning towards #2.

#5 Updated by Derik Barseghian about 8 years ago

Ben and I brainstormed a bit on this too, we might be able to go with option 1), utilize Reporting, by adding some new features to Reporting. These would also be generally utilizable and improve Reporting.
E.g. new 'workflow summary' and 'actor summary' report designer items. In the generated instance, the actor/workflow parameters would be filled in.
We could also add a workflow thumbnail item.
Also, more general details could be included e.g. in the footer, like workflow and execution lsids, date, workflow name, etc.

#6 Updated by Derik Barseghian about 7 years ago

Changing target to reporting-2.x.y -- if we go with proposed soln in comment#5, this is a feature to add to reporting.

#7 Updated by Redmine Admin about 6 years ago

Original Bugzilla ID was 4746

Also available in: Atom PDF