Bug #5083
closed
possible to save a kar that loses the report layout
Added by Derik Barseghian almost 14 years ago.
Updated about 13 years ago.
Description
This seems like a problem with the ObjectManager.
Scenario:
User A uses Save Archive to create test.kar, it contains a workflow and report layout
User A sends test.kar to User B, who places it on his desktop (not his kepler "local repository")
User B launches Kepler, then uses Open Archive to open test.kar, and notes he can see workflow and layout
User B changes the workflow in some small way, and workflow thus gets a new LSID
User B uses Save Archive to save test2.kar
test2.kar only contains the workflow, and not the report layout
This is because the ReportLayoutKAREntryHandler (and other handlers) tries to get the workflow out of the ObjectManager using getObjectRevision( the workflow's (new) LSID), and this returns null. I'm not sure why this is yet. A simple fix seems to be adding the workflow into the OM during KARBuilder handleInitiatorList() if getObjectRevision is currently returning null. I'm first trying to determine why this seems to be necessary for this scenario, and not the same scenario above except where test.kar is "local" (created by User B)...
I've implemented a stopgap to this bug, with the following comment, in WorkflowManager so that reporting 2.0 can depend on kepler 2.0. This stopgap should be removed and a fix incorporated in kepler suite.
// TODO this is a stopgap for http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5083
// This should be removed and a fix incorporated into kepler suite, probably not by simply
// moving this code there (though that would be better than having it here -- other modules'
// KAREntryHandlers should be able to fetch the workflow using getRevision -- somewhere like
// KARBuilder.handleInitiatorList) but by determining why, when a workflow's LSID changes,
// we can no longer able to fetch the workflow from ObjectManager using getRevision.
This is fixed in 2.0, but needs to be merged into trunk.
This was merged into trunk.
Still need to look into removing stopgap.
Re: comment#3, stopgap no longer seems necessary -- I commented it out and tested the scenario in the bug description (actually tested a few -- both save and save as, in KeplerData and not), and it's working now. I've committed this change (r26883), and if no errors crop up, will close this bug in the near future.
Yeah, seems fixed, haven't gotten this to recur, and I just tested again. Closing.
Original Bugzilla ID was 5083
Also available in: Atom
PDF