Bug #4977
closed
Can't associate multiple sets of reporting artifacts in one kar with different executions
Added by Derik Barseghian about 14 years ago.
Updated about 14 years ago.
Description
Reporting artifacts from imported runs are no longer being put into provenance since reporting attributes are no longer stored in the WorkflowRun. I'll change the code to instead look for and insert all items found in the kar manifest that use handlers ReportLayoutKAREntryHandler or ReportInstanceKAREntryHandler.
Since reporting items dependOn the workflow and not the workflowRun, this is another tripping up point for multiple runs in one kar -- how will we know which reporting artifacts to associate with which run? I think putting multiple runs in one kar will require reporting artifacts dependOn the execution lsid.
Made that change, so artifacts are being inserted, but leaving this bug open since this procedure won't work for run-kars that contain multiple runs and sets of reporting artifacts.
Changing the title of this bug and adding dependency.
To reiterate - if it were possible to make a KAR with multiple sets of reporting artifacts (there's a bug with romls at the moment http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4896), my code for importing them into provenance won't be able to associate them with particular executions, because they only depend on the workflow, not execution. Maybe reporting items could be made to dependsOn both the workflow and run as necessary.
believe i have this working locally, but reporting's incrementRevision stuff needs to change a bit, esp in regard trying to roll rev on lsid with different namespace
was fixed at r24481 (trunk) and r24483 (2.0). Made reporting items depend on run when exporting a run-kar, and on import utilizing these dependencies.
Issues with reportLayout lsid incrementing properly and reportLayout maintaining a referral list should be put into a new bug.
Original Bugzilla ID was 4977
Also available in: Atom
PDF