Kepler

It looks like a workaround is to transfer the InstanceAuthNamespace file from one computer to the other. It requires a clean-cache before loading.

Transporting the InstanceAuthNamespace is unacceptable.
One of the major reasons for having KARs is for sharing them among people (and computers).
If you save a KAR and then send it to me, do I loose the report layout?

svn co https://code.ecoinformatics.org/code/kruger/trunk/workflows/tpc01-buffalo-tb

There should be a KAR in there as well as an InstanceAuthNamespace for you to test.

The workflow in question has an LSID of:
urn:lsid:gamma.msi.ucsb.edu/OpenAuth/:964:30:97
when I step through opening the KAR file in debug mode I can see that the report layout is correctly opened and added to the manager with the correct workflow association. The problem seems to be that the opened workflow then gets an LSID assigned to it using my AuthNamespace prefix (a new LSID) and the workflow<->report layout association does not exist.
The LSID change happens somewhere during the openModel() methods (in ptolemy?) so that by the time we hit KeplerGraphFrame we have a new LSID for the NamedObj (workflow).
I do see the old LSID in the "derivedFrom" list so my hunch is that there's a changer request that is forcing the new LSID generation.

also: just opening a plain old XML workflow file from a different InstanceAuthNamespace results in a new LSDI being assigned (and the original one becoming part of the derived from list).

this should work now that the LSID is not being changed when the workflow opens in a new namespace (kepler) instance

Original Bugzilla ID was 4527