Kepler

This is because there can be multiple KARS that depend upon the same workflow, but have been saved with different report layouts. When a report layout is opened, it currently only looks up the workflow lsid and nothing else, and has no way to associate an array of reports with a single workflow, and know which one should be used for the currently selected frame.

Retargeting - this seems like something we should fix for wrp-2.0. It's possible to open a KAR, redesign the report, and then open another KAR and lose the redesigned report when it's refreshed.

I spent a bit looking into this last night. I was able to keep the report layout from refreshing in the window in which it shouldn't, but this isn't enough. When you execute, the old report layout is still used (instead of the one shown) -- so this ends up being more confusing/worse. To really solve this problem, some refactoring needs to be done in a few places for Workflow to truly be keeping track of different report layouts per workflow. This isn't hard. However, there are places, like in the reporting kar entry handlers, where reporting only has a workflow lsid to work with, but additional context is needed to be able to know which report for this workflow to use. This might mean keeping a mapping of reportlayout to frame/window/whatever. Doing this, and in a way that works for both gui and headless, might be non-trivial, and seems likely to introduce bugs along the way. At this juncture we may want to leave this bug in, and retarget to wrp-2.x.y....

Based on Deriks comments, re-targeting to wrp-2.x.y for now.

retargeting

Should be fixed in 2.0 now at r25056. Needs to be merged into trunk.

I merged a long time ago, just tested on trunk and works.

Original Bugzilla ID was 5009