Bug #4132

Workflow Run Manager - Open in New Window is just opening the workflow, not the ROML or report

Added by Derik Barseghian over 9 years ago. Updated about 9 years ago.

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


Estimated time:


Open in New Window should open not just the workflow, but the roml and report (anything else?).

Related issues

Blocked by Kepler - Bug #3655: create a Workflow Run Manager with ability to export Publication Ready ArchivesNew2008-11-12

Blocked by Kepler - Bug #4457: Workflow Run Manager - past Report Layouts don't openResolved2009-10-14


#1 Updated by ben leinfelder over 9 years ago

We can open the ROML - that'll make sense. Not sure how we would want to "open the report" - right now that UI is based on the latest execution of the open workflow's lsid. Maybe that's exactly what we want, actually!
I'll work with Derik on getting the ROML into memory from provenance

#2 Updated by Derik Barseghian over 9 years ago

I remembered why I've been punting on this: the dependency issues. When opening a run via the workflow-run-manager, it's possible the user is just using the workflow-run-manager suite, not wrp, for example, so the report items can't be opened. I.e., how does WRM know what all to open from the kar, which could conceivably contain all sorts of things used by other modules? Probably the answer is to switch to using the existing Open KAR mechanism, which I believe works similarly to Save KAR (modules registering and e.g. saving/opening/etc the appropriate karentries).

One problem here is that we don't actually have the run-kars in provenance, just the component items. Two possible solns come immediately to mind: 1) put run-kars into provenance or 2) build the kar when (before) trying to open a run. Neither option seems especially good to me at the moment...

#3 Updated by Derik Barseghian about 9 years ago

I've gotten option 1 to work locally: when opening (a) run(s) from WRM, just build a temp kar and then open it. This has the benefit of essentially using the same code as the Open Archive action, so new code won't have to be added if in the future we add things to KARs. To do this I exported the run(s) to a temp KAR file. Then you must create a KARFile from this, call KARFile.cacheKARContents(), and then you may open it. However, I first had to remove a check in cacheKARContents that requires the KAR first be in the local repo (I don't want temp files showing up in the local repo). This procedure seems to work fine, everything opens. I discussed why this requirement is here with Aaron -- it's here to ensure the local repo is a reflection of what's in cache. Also, if someone were to open a run via the procedure I just created, then were to click the Sources=>Build (or Refresh in the tree when this action is implemented) button which syncs the local repo(s) w/ cache, my items would be cleared, and any subsequent call to cache looking for them would fail (maybe changing from the workflow tab to the report designer or report tab causes a lookup from cache, I'm not sure offhand).

So, we discussed an alternate solution which leaves the design requirement that allows the local repo(s) and cache stay in sync -- change open to not require things first be in cache. If it's not in cache, just open it. This would fix the bug where kars cannot be opened from arbitrary locations. This means refactoring -- any calls in things like karentryhandlers that obtain things out of cache should also be able to fall back on trying to just open the items out of the kar.

I'm not clear on how much work this will be, I'm going to start trying to see...

#4 Updated by Derik Barseghian about 9 years ago

Unless I missed something, this turned out to not be so bad, and I've got it working locally. I'll check in after more testing tomorrow. There's an issue with workflow window title names, and sometimes ROMLs still don't show up -- I think this happens in cases when two ROMLs are saved in the kar, and one is blank, and probably the blank is opened. Maybe this was the problem with "ROMLs not showing up" before this refactor too...

#5 Updated by Derik Barseghian about 9 years ago

r21539 should fix this, going to leave open for a bit for others to test...

#6 Updated by Redmine Admin over 5 years ago

Original Bugzilla ID was 4132

Also available in: Atom PDF