https://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-05-20T18:34:27ZEcoinformatics RedmineKepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173292010-05-20T18:34:27Zben leinfelderleinfelder@nceas.ucsb.edu
<ul></ul><p>are report layouts now NamedObjs or something?<br />Where is the referral list stored if not?</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173302010-05-20T18:47:27ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>They're still not NamedObjs. Unfortunately the constructor for NamedObjIdReferralList needs a NamedObj. Aaron recommended refactoring NamedObjIdReferralList, or having reportLayout keep a NamedObj member to serve as proxy. The latter seems kludgy, but may be the way to go since we're trying to ship 2.0.</p>
<p>One problem currently is that reporting attempts to increment the LSID even if it's from a different namespace, and this is not allowed and thus gives errors. The ideal thing here would be to keep a referral list. One cheat, if we don't care about the origins of a reportLayout, is to simply create a new lsid and discard the old.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173312010-05-20T18:55:25Zben leinfelderleinfelder@nceas.ucsb.edu
<ul></ul><p>Hmm, I'm trying to think of how we'd use the "provenance of the report layout". I suppose that could be useful for undo/redo operations? But it seems like we don't have an immediate need to keep track of history, the more pressing need is to avoid nasty exceptions when trying to update the LSID.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173322010-05-20T19:12:41ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>It might also be nice to see who originally created and who contributed to a report layout, esp in a 'publication kar'. But I agree, discarding may be more prudent at this juncture.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173332010-06-07T21:50:36Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>The report layout LSID is now incremented whenever the user saves a KAR file, but only if it is in the local namespace. If it is not a local instance, we have decided NOT to add it the referral list at this time. Seems to be working well, closing this bug now if there are no objections.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173342010-06-07T22:42:34ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>Hey Debi, while it may be ok to only increment the LSID whenever a report layout is saved, one of the ways a report layout is saved is to provenance when the workflow is run. So if the LSID now only increments during a save to KAR, that won't be sufficient because of the following scenario:</p>
<p>1) Design a workflow and report layout<br />2) Execute (call this run1)<br />3) Change the report layout<br />4) Execute (call this run2)<br />5) Export to KAR run1<br />6) Export to KAR run2</p>
<p>run1.kar and run2.kar now contain two different report layouts, but each with the same LSID.</p>
<p>Less important, but just to note: another reason I'm not a fan of this approach is that you can design a workflow and report, save to kar, then save to another kar, and you then have two report layouts that are essentially identical, but simply have different LSIDs (the LSID is the only thing keeping them from being the same).</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173352010-06-07T23:15:02Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>So, just to be sure that I am understanding you correctly -- are you saying that using the ReportLayoutKAREntryHandler for this purpose is not sufficient ? and that we need to increment it when the workflow runs as well ? Can you suggest what you think the best approach to doing that would be ?</p>
<p>Currently, doing it in the ReportLayoutKAREntryHandler using saveReportLayout, does seem to be working very reliably, and I hate to change that.</p>
<p>Thanks.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173362010-06-08T17:57:59ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>Yes, it's not sufficient because scenarios like comment#6 are still possible.</p>
<p>I think the best approach is to roll the report layout's LSID whenever the report layout is changed.</p>
<p>If you don't want to do it this way, but instead only on saves, then you need to roll it before any save, which includes before the save to provenance when the workflow is run.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173372010-06-09T19:38:06Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>(In reply to comment <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: element without attribute causes null pointer exception (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/8">#8</a>)</p>
<blockquote>
<p>Yes, it's not sufficient because scenarios like comment#6 are still possible.</p>
<p>I think the best approach is to roll the report layout's LSID whenever the<br />report layout is changed.</p>
<p>If you don't want to do it this way, but instead only on saves, then you need<br />to roll it before any save, which includes before the save to provenance when<br />the workflow is run.</p>
</blockquote>
<p>O.K. sounds like a good idea. I have now had it update the revision whenever files are written to Provenance as well. Does that seem like it will adequately address the issues you have described ?</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173382010-06-09T20:01:20Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: Win 98 Not recognized - error in getting working dir (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/9">#9</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: element without attribute causes null pointer exception (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/8">#8</a>)</p>
<blockquote>
<p>Yes, it's not sufficient because scenarios like comment#6 are still possible.</p>
<p>I think the best approach is to roll the report layout's LSID whenever the<br />report layout is changed.</p>
<p>If you don't want to do it this way, but instead only on saves, then you need<br />to roll it before any save, which includes before the save to provenance when<br />the workflow is run.</p>
</blockquote>
<p>O.K. sounds like a good idea. I have now had it update the revision whenever<br />files are written to Provenance as well. Does that seem like it will<br />adequately address the issues you have described ?</p>
</blockquote>
<p>Also I have now tested this using the same steps described in your Comment <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: MCAT won't build under IRIX with Oracle 8.0.5 (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/6">#6</a>.<br />Upon viewing the ROML LSIDS for each run, they are now different, as well as incremented sequentially by 1, each time the workflow is run, AND/OR each time a KAR is saved.</p>
<p>Please review and let me know if you agree, so that we can close this bug for now.<br />Thanks.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173392010-06-09T20:10:15ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>Sounds good. Can you poke around looking for any other similar problems -- e.g. what happens when you have multiple copies of the same report open (same LSID), make changes to one, but switch to the original window and execute that workflow? There exist in the system at that moment two report layouts with the same LSID. Hopefully the right report is used and has its LSID incremented, and hopefully the other report doesn't lose its changes, will have it's LSID incremented and be saved to prov when that wf is run, etc.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173402010-06-14T19:21:25Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: ibm xml parser jar file missing or corrupted (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/11">#11</a>)</p>
<blockquote>
<p>Sounds good. Can you poke around looking for any other similar problems -- e.g.<br />what happens when you have multiple copies of the same report open (same LSID),<br />make changes to one, but switch to the original window and execute that<br />workflow? There exist in the system at that moment two report layouts with the<br />same LSID. Hopefully the right report is used and has its LSID incremented, and<br />hopefully the other report doesn't lose its changes, will have it's LSID<br />incremented and be saved to prov when that wf is run, etc.</p>
</blockquote>
<p>After testing I have found that what happens in this case, is that when you open two copies of the same workflow, select one of them, make changes to one, then switch to the original window and execute that workflow, then the LSID for the report layout is incremented at that point. There are no longer 'two' report layouts. There is one current layout, and one layout that has (in essence) been changed (by running the workflow) but not saved. If you switch to the workflow in either window they will both show the same LSID for the report layout. If you go to that window where the first change was made it will always reload the layout from the workflow no matter what. This is something that we chose not to address for this release and can be referenced in Bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Opening two KARS that have the same Workflow, but that have different report layouts, will make t... (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/5009">#5009</a> (i.e. Opening two KARS that have the same Workflow, but that have different report layouts, will make the first layout refresh itself with the layout from the KAR that was opened most recently.) which still applies.</p>
<p>Can I suggest that this is satisfactory for now and that we should close this bug ?</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173412010-06-14T20:12:19ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: compilation error in mde (FormViewTable.java) (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/12">#12</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: ibm xml parser jar file missing or corrupted (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/11">#11</a>)</p>
<blockquote>
<p>Sounds good. Can you poke around looking for any other similar problems -- e.g.<br />what happens when you have multiple copies of the same report open (same LSID),<br />make changes to one, but switch to the original window and execute that<br />workflow? There exist in the system at that moment two report layouts with the<br />same LSID. Hopefully the right report is used</p>
</blockquote></blockquote>
<p>I gave the above a try, and what I found (by looking at the generated report) is that the wrong layout is used (the other window's layout--the one modified by user-- is used).</p>
<blockquote><blockquote>
<p>and has its LSID incremented, and<br />hopefully the other report doesn't lose its changes, will have it's LSID<br />incremented and be saved to prov when that wf is run, etc.</p>
</blockquote>
<p>After testing I have found that what happens in this case, is that when you<br />open two copies of the same workflow, select one of them, make changes to one,<br />then switch to the original window and execute that workflow, then the LSID for<br />the report layout is incremented at that point. There are no longer 'two'<br />report layouts. There is one current layout, and one layout that has (in<br />essence) been changed (by running the workflow) but not saved. If you switch<br />to the workflow in either window they will both show the same LSID for the<br />report layout.</p>
</blockquote>
<p>How are you looking at the report layout here? I'm confused.</p>
<blockquote>
<p>If you go to that window where the first change was made it<br />will always reload the layout from the workflow no matter what.</p>
</blockquote>
<p>Confused here also. For the above scenario, my unmodified layout stays unmodified in the gui. This bug would be a little less confusing if the layout did refresh to show the changes in the other window, since they will be used during execution.</p>
<blockquote>
<p>This is<br />something that we chose not to address for this release and can be referenced<br />in Bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Opening two KARS that have the same Workflow, but that have different report layouts, will make t... (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/5009">#5009</a> (i.e. Opening two KARS that have the same Workflow, but that have<br />different report layouts, will make the first layout refresh itself with the<br />layout from the KAR that was opened most recently.) which still applies.</p>
<p>Can I suggest that this is satisfactory for now and that we should close this<br />bug ?</p>
</blockquote>
<p>I wouldn't close it because I'm guessing incrementing the lsid whenever the report layout is changed is a good way to solve the bug. If we want to add a caveat about not being able to have two copies of the same workflow+report layout pair opened at once then we could maybe postpone the bug.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173422010-06-14T20:39:53Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>(In reply to comment <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: metacat doesn't allow updates or deletes (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/13">#13</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: compilation error in mde (FormViewTable.java) (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/12">#12</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: ibm xml parser jar file missing or corrupted (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/11">#11</a>)</p>
<blockquote>
<p>Sounds good. Can you poke around looking for any other similar problems -- e.g.<br />what happens when you have multiple copies of the same report open (same LSID),<br />make changes to one, but switch to the original window and execute that<br />workflow? There exist in the system at that moment two report layouts with the<br />same LSID. Hopefully the right report is used</p>
</blockquote></blockquote>
<p>I gave the above a try, and what I found (by looking at the generated report)<br />is that the wrong layout is used (the other window's layout--the one modified<br />by user-- is used).</p>
<blockquote><blockquote>
<p>and has its LSID incremented, and<br />hopefully the other report doesn't lose its changes, will have it's LSID<br />incremented and be saved to prov when that wf is run, etc.</p>
</blockquote>
<p>After testing I have found that what happens in this case, is that when you<br />open two copies of the same workflow, select one of them, make changes to one,<br />then switch to the original window and execute that workflow, then the LSID for<br />the report layout is incremented at that point. There are no longer 'two'<br />report layouts. There is one current layout, and one layout that has (in<br />essence) been changed (by running the workflow) but not saved. If you switch<br />to the workflow in either window they will both show the same LSID for the<br />report layout.</p>
</blockquote>
<p>How are you looking at the report layout here? I'm confused.</p>
<blockquote>
<p>If you go to that window where the first change was made it<br />will always reload the layout from the workflow no matter what.</p>
</blockquote>
<p>Confused here also. For the above scenario, my unmodified layout stays<br />unmodified in the gui. This bug would be a little less confusing if the layout<br />did refresh to show the changes in the other window, since they will be used<br />during execution.</p>
<blockquote>
<p>This is<br />something that we chose not to address for this release and can be referenced<br />in Bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Opening two KARS that have the same Workflow, but that have different report layouts, will make t... (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/5009">#5009</a> (i.e. Opening two KARS that have the same Workflow, but that have<br />different report layouts, will make the first layout refresh itself with the<br />layout from the KAR that was opened most recently.) which still applies.</p>
<p>Can I suggest that this is satisfactory for now and that we should close this<br />bug ?</p>
</blockquote>
<p>I wouldn't close it because I'm guessing incrementing the lsid whenever the<br />report layout is changed is a good way to solve the bug. If we want to add a<br />caveat about not being able to have two copies of the same workflow+report<br />layout pair opened at once then we could maybe postpone the bug.</p>
</blockquote>
<p>To document our conversation from the REAP meeting today, it sounds like the more basic problem to all of this is the fact that the KAR only references the last report layout that is generated. We should definitely address this as soon as possible. However, since it will take a significant effort and will have a fairly wide impact - it may need to be delayed until the next release.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173432010-06-21T22:06:43Zdebi staggsstaggs@nceas.ucsb.edu
<ul></ul><p>(In reply to comment <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: metacat TEXT nodes limited to 4K characters (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/14">#14</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: metacat doesn't allow updates or deletes (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/13">#13</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: compilation error in mde (FormViewTable.java) (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/12">#12</a>)</p>
<blockquote>
<p>(In reply to comment <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: ibm xml parser jar file missing or corrupted (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/11">#11</a>)</p>
<blockquote>
<p>Sounds good. Can you poke around looking for any other similar problems -- e.g.<br />what happens when you have multiple copies of the same report open (same LSID),<br />make changes to one, but switch to the original window and execute that<br />workflow? There exist in the system at that moment two report layouts with the<br />same LSID. Hopefully the right report is used</p>
</blockquote></blockquote>
<p>I gave the above a try, and what I found (by looking at the generated report)<br />is that the wrong layout is used (the other window's layout--the one modified<br />by user-- is used).</p>
<blockquote><blockquote>
<p>and has its LSID incremented, and<br />hopefully the other report doesn't lose its changes, will have it's LSID<br />incremented and be saved to prov when that wf is run, etc.</p>
</blockquote>
<p>After testing I have found that what happens in this case, is that when you<br />open two copies of the same workflow, select one of them, make changes to one,<br />then switch to the original window and execute that workflow, then the LSID for<br />the report layout is incremented at that point. There are no longer 'two'<br />report layouts. There is one current layout, and one layout that has (in<br />essence) been changed (by running the workflow) but not saved. If you switch<br />to the workflow in either window they will both show the same LSID for the<br />report layout.</p>
</blockquote>
<p>How are you looking at the report layout here? I'm confused.</p>
<blockquote>
<p>If you go to that window where the first change was made it<br />will always reload the layout from the workflow no matter what.</p>
</blockquote>
<p>Confused here also. For the above scenario, my unmodified layout stays<br />unmodified in the gui. This bug would be a little less confusing if the layout<br />did refresh to show the changes in the other window, since they will be used<br />during execution.</p>
<blockquote>
<p>This is<br />something that we chose not to address for this release and can be referenced<br />in Bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Opening two KARS that have the same Workflow, but that have different report layouts, will make t... (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/5009">#5009</a> (i.e. Opening two KARS that have the same Workflow, but that have<br />different report layouts, will make the first layout refresh itself with the<br />layout from the KAR that was opened most recently.) which still applies.</p>
<p>Can I suggest that this is satisfactory for now and that we should close this<br />bug ?</p>
</blockquote>
<p>I wouldn't close it because I'm guessing incrementing the lsid whenever the<br />report layout is changed is a good way to solve the bug. If we want to add a<br />caveat about not being able to have two copies of the same workflow+report<br />layout pair opened at once then we could maybe postpone the bug.</p>
</blockquote>
<p>To document our conversation from the REAP meeting today, it sounds like the<br />more basic problem to all of this is the fact that the KAR only references the<br />last report layout that is generated. We should definitely address this as<br />soon as possible. However, since it will take a significant effort and will<br />have a fairly wide impact - it may need to be delayed until the next release.</p>
</blockquote>
<p>After the REAP meeting today, Matt, Derik, and I discussed some of the issues related to this bug. In the course of our discussion the following problem was described:</p>
<p>Window 1<br /> Workflow [A] KAR 0<br /> Layout [0]</p>
<p>Window 2<br /> Workflow [A] KAR0 -> KAR1<br /> Layout [0] -> Layout<sup><a href="#fn1">1</a></sup></p>
<pre><code>Workflow [B]<br /> Layout [1]<br /> Layout [2]<br /> Layout [3]</code></pre>
<p>The following solutions were proposed:</p>
<p>1. LayoutChangedEvent to sync layouts on change via refresh<br /> -- might be hard, and isn't the right direction</p>
<p>2. Support mulitple layouts per wf<br /> -- a. gui menu to save layout, menu to switch in RD, menu to<br /> switch in report viewer, render mutliple reports.<br /> -- b. could just allow layouts to diverge, association maintained in manager <br /> that uses tableau window and layout ID (rather than Worflow LSID)</p>
<p>3. Don't allow the same wf to be opened more than once<br /> -- would limit the ability of WRM to open multiple runs of same wf.</p>
<p>After some discussion, we decided that solution 2b would provide the best functionality at this time, and would result in application behaviors that users could reasonably anticipate.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173442010-07-01T01:16:50ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>As of r25050 I believe I have the report LSID being properly maintained - if the user deletes, adds, rearranges, or edits report items, or changes their properties, or changes the title, the LSID will roll. This could be improved, but I think it's ok as is. <br />(Improvements:<br />- all text areas use a DocumentListener for changes, so any letter you type or delete rolls the LSID - if the GUI required the user do something to 'complete' their changes to any given text area, I could then do a comparison between the old and new values and only roll the LSID once.<br />- the image report item will roll LSID whenever the user clicks on the '+ Get Image' button - it would be better to compare new and previous Images to see if they are different before rolling LSID<br />- when dragging a panel and dropping it back in the location from which you started will roll the LSID - no need to roll here<br />)</p>
<p>We decided to not maintain the referral list, so if the report has a non local lsid it gets tossed and a new one is used.</p>
<p>These changes are in 2.0 only for now, I'll merge into trunk later.</p>
<p>Now the issue in comment#15 and bug#5009 can probably be addressed.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173452010-07-06T21:07:40ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>Comment#15 should be fixed now in 2.0 at r25056. Needs to be merged into trunk.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173462011-02-01T23:06:32ZDerik Barseghianbarseghian@nceas.ucsb.edu
<ul></ul><p>I'm having trouble understanding the "problem" described in comment#15 at this point, so I'll just trust my comment#17 saying I fixed comment#15. I merged everything a long time ago, so closing.</p> Kepler - Bug #5017: ReportLayout LSID and referral list should be maintainedhttps://projects.ecoinformatics.org/ecoinfo/issues/5017?journal_id=173472013-03-27T21:28:55ZRedmine Admin
<ul></ul><p>Original Bugzilla ID was 5017</p>