Kepler

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

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

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

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

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

Original Bugzilla ID was 4132