Resetting preferences removes duplicates.

reset prefs > open IGB 9.0.0 > no duplicates
reset prefs > open IGB 9.0.1 > no duplicates

reset prefs > open IGB 9.0.0 > open IGB 9.0.1 > see duplicates

Users may notice the duplicates and choose to reset prefs, but that's not ideal AND reseting prefs also looses any non-default quickload sites.

Please see this branch:

https://bitbucket.org/IvoryBlak/integrated-genome-browser/branch/IGBF-1206

To see the problem:
reset prefs > open IGB 9.0.0 > open IGB 9.0.1 > see duplicates

To test the fix:
reset prefs > open IGB 9.0.0 > add custom quickload sites > close 9.0.0 > open IGB 9.0.1

You should see the SoySeq site, but no Pollen or Cytokinin.
Blueberry should appear exactly once.
Any custom sites you added should be preserved.

First Level Review:

The issue passes the first level review. IGB 9.0.1 behaves as expected, it removes the duplicates and keeps the user entered URLs having same names as default URLs.

After Testing: IGB 9.0.0

After Testing: IGB 9.0.1 works as expected (Compare with IGB 9.0.0 image to see changes)

After review this fix with Ann, we discovered that it was incomplete. We actually do need to integrate an id component into the default data providers.

We are working on a new fix.
This branch is one draft of the fix using an id.
IGBF-1206_draft2
https://bitbucket.org/IvoryBlak/integrated-genome-browser/branch/IGBF-1206_draft2

Issue passed first level review.

Issue was tested with all test cases except testing the quickloads that need username and password.

Modified the return type of "getDataProviderById" method to BaseDataProvider.

Fix can be found at:
https://bitbucket.org/djoshi4/deepti-fork-igb/branch/IGBF-1206_Duplicate_Sites_Issue

Tested the solution for all cases except the quickloads with username and password. The fix passes all tests.

Somehow--some magical how--The table of data providers knows which data providers should be editable, and which should not.

The table's class assumes that editable is true. So if editable is not set in a data provider, then its assumed to be editable. If it has editable set to false, then it is not editable.
All data providers were read from the json file have 'false' in the editable field.
This is the case if the json node has isEditable="false", or isEditable="true", or isEditable is missing. Somehow the DataProviderConfig always gets editable=false, even if the json file says true. I can't find what makes the DataProviderConfig object, or how those objects get put into the ArrayList called dataProviders as a field in the IgbPreferences object.
I just know that somehow, by the time we call IgbPreferences.getDataProviders(), they all have editable=false, regardless of the isEditable tag in the json file.

Somehow, the process that reads in default IGB prefs always sets editable to false for the dataProvider, and the data provider table (the gui) assumes things should be editable=true, unless they are false. The user-provided dataProviders have no way to set editable, so ... we get the ideal functionality, so its not broken. So I think its ok to give up on this.

The migrateOldDataProviders() method was introduced in May 2015 immediately after substantial refactoring about the DataProvider class. It was intended to migrate old dataProviders ("servers") from IGB 8.3 to IGB 8.4.

This method includes a set of fixed urls that it prevents from transfering.

The attached document "isEditable.docx" provides some details about how the isEditable tag is/was used for the Data Sources table, and how the Data Sources table was able to correctly allow editing for user-provided data providers but not allow it for default ones.

The document can serve as an example of investigating and trouble-shooting code. However, the document says nothing of all the many dead-ends that were ruled out to get to this point.

My testing confirms that this story is now resolved. I am not able to reproduce duplication of QL sites when opening 9.0.1 after opening 9.0.0. However, I am able to see duplicate QL sites when running 9.0.0 after 9.0.1, but I am thinking that this is expected, although not ideal. I will run this question by the team to verify that this is expected, but for now, I am marking as closed.