Bug #4746


ability to create a Site Layout report

Added by Daniel Crawl about 14 years ago. Updated about 12 years ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Estimated time:


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

Related issues

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

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

Actions #1

Updated by Daniel Crawl about 14 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.

Actions #2

Updated by Derik Barseghian almost 14 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.

Actions #3

Updated by Derik Barseghian about 13 years ago

changing bugs from REAP to Kepler product

Actions #4

Updated by Derik Barseghian about 13 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.

Actions #5

Updated by Derik Barseghian about 13 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.

Actions #6

Updated by Derik Barseghian about 12 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.

Actions #7

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 4746


Also available in: Atom PDF