Kepler

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.

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.

changing bugs from REAP to Kepler product

• 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.

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.

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

Original Bugzilla ID was 4746