<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-02T16:14:42Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Verified with datapro versions 4.0.1003.49231, 4.1.360.49222 and 4.2.48.49229.

Tested by adding a group with hw and 3 channels  , then creating a test adding the group to the test then changed hw in the test  and ran test tirggered.

Navigated to the download tab for each version and the prepatched version , in the per patched version of 4.0  both the slice pro hw and the s6air that was removed from the test   showed up in the download tab &gt; hw step .

In all 3 of the patched versions the correct hw showed up in the download step that was part of the test .

</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-07-21T22:20:48Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-13T15:38:20Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-07-05T20:26:03Z</TimeStamp>
    <ReleaseNote>Corrects an issue where static group DAS were also connected to in the download tab</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-05T16:57:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-05T15:41:12Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-05T15:41:07Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-28T20:49:42Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1/4.2@49142
 
I think there's an easy way to duplicate it.
 
Create a static group with a set of hardware.  Create a test setup with that static group.  Change the hardware in the test setup.  Run the test.  Go to download.  Pre-patch you should see both the old hardware in the test and the new hardware, leading to some confusion as it would try to connect to the old hardware as well. 
 
Looking into the code it seems it does this because of an interaction with the static groups and the embedded dynamic groups in the test setup.  I think this issue has probably existed more or less for a long time, maybe not Day 0, but probably for a very long time.  I chose kind of a minimalistic patch to address the issue.  Since the import of the test setup creates a test setup that looks correct I think only the download tab _needs_ tab corrected.  The patch now calls a function which coalesces the hardware to just the hardware for the static groups, which corrects the issue.  It only does this for the download tab.
 
Additional things that should be tested - you should be able to download from a blank database with just the test setup xml - the patched code doesn't address this either way, so it's expected to work.  If it was broken before the patch, it's probably still broken, but the patch shouldn't break this feature.</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-06-28T20:49:37Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-28T15:01:30Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Export is doing this because of the static test groups corresponding to the embedded groups still have the hardware selected.
 
I sent this email to support:
 
I've discovered an odd behavior in DP that I'm about to correct, but wanted to make a note of it.
 
http://manuscript.dts.local/f/cases/31861/Emergency-download-is-using-DAS-that-isn-t-in-the-test-setup-that-was-run
 
With this issue I ran a test setup with only a USB SPS, but when I went to the download tab 5 DAS connected rather than the 1 I ran with.
 
here's the hardware I ran with;
 
 
now in the test setup the XML that I ran with contains all the hardware in it's DASList
 
 
at first glance this seems wrong and it might be, but if you delete the test setup and import it clean you'll see the same only 1 das selected.
 
What happened behind the scene is that there were two static groups in the database and the test setup makes use of those two groups.  The test setup xml that is exported contains both the static groups and the embedded groups that are in the test setup.  Now in the test setup I had only the SPS00330 selected.
 
 
I think we've probably seen this for a long time and had just never tracked it down because it's a bit of a corner case.  Where you would see this is a place that uses static groups but then may change hardware at a test setup level without updating the static groups.  This may be a use case that WIAMan has run into when they replace a S6 for not booting, they may deselect the outgoing das in the test setup and select the new DAS, and leave the static groups as they were.  In this case I would expect an emergency download to connect to the new DAS but also try to connect to the old das.
 
This is not a critical issue in that you should be able to download, but it would be confusing at best because you would see missing das and it'd be a DAS if you were paying attention to was no longer in the test setup.
 
I'm guessing this issue has been live for a long time and was just noticed now.  I'm planning on patching in 4.0 and on.  I plan on correcting it by changing how the emergency download decides what das it needs and leaving the xml import and export as they are.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-27T18:10:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>PrepareForExport has 5 DAS in includedDAS, in ExportCurrentTestSetup while CurrentTest only has 1 DAS.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-27T17:08:50Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>you can see the hardware is not selected here:
 
 
you can see in the test setup xml that is exported all the hardware IS included there;</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-27T17:01:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-06-23T15:31:18Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>the test setup that is written doesn't exactly reflect that test setup that is committed or running?</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-22T14:10:44Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-06-21T22:16:40Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>observed by dan when using jerry's test setup then substituting a USB SPS into the test and running it.</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-06-21T22:16:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>