Coloring should be enabled only if tracks are of same type

Devdatta, I am not seeing this issue as resolved. When I select multiple tracks and use the color by feature, only one track gets colored. I verified that all tracks are of the same file type but this is still not working for me, so I am reassigning to you and moving back to the To-Do column. Please let me know if there is something I am misunderstanding about this issue.

I almost thought this story was resolved and almost closed it because all selected tracks are being colored properly when the color by feature is applied. However, I started noticing strange behavior as I continued to test. It appears that once a track has been colored as a group of tracks, coloring any of the tracks from the group results in the other tracks from the group being colored as well, even if the track is no longer selected. I know this is confusing, but maybe this scenario will help clear up any confusion:

Currently, if I color tracks "A" and "B" with "Heatmap Setting 1", and then color tracks "B" and "C" with "Heatmap Setting 2", track "A" also gets "Heatmap Setting 2" applied when it should remain at "Heatmap Setting 1" (it does appear that "Heatmap Setting 1" stays in the Heatmap Editor's memory for that track, though, which is correct.)

This issue I've found requires at least 3 tracks to reproduce. For now, I am re-assigning to Devdatta and moving back to the To-Do column. Please let me know if you have any questions.

It was a nice catch. I have fixed the issue.
Let me know if you find any more bugs

It may have been a nice catch, but it was an even nicer fix...very quick! It seems that part is now fixed, but I am actually noticing another thing related to this story. It seems that if I apply a heatmap setting to a track, and then select that track and another track and apply a different heatmap setting, the heatmap setting that gets remembered is not necessarily the one that is currently applied. Instead, it seems that the track's "individual heatmap setting" is always remembered, not the "group's heatmap setting".This could be by design, and not a bug, but I think this could be confusing to users because after I apply a heatmap settings to a group of tracks, as a user, I would want that same heatmap setting to be the one remembered when I restart IGB. Instead, it may remember an older heatmap setting that I applied to an individual track, but I think as a user I would not care about that older heatmap setting anymore because I already chose to apply another heatmap setting to the group of tracks. I made a quick screencast and attached it to this story to help illustrate the problem, but if you have any questions, please let me know. I'm moving back to To-Do now and reassigning to Devdatta.

Yes, your observation about "history" in heatmap is correct but that is expected behavior, at lease for now, because as per current design, we do not have a decent way to do it.

Seems like if igb can save heat map setting one selected track, it would be possible to save it for multiple selected tracks. Can you walk us through it in our next team meeting?

Yes sure, we can discuss it in meeting.

Ann and Devdatta recently spoke about the issue of only the "individual" heatmap setting being remembered and they decided to make it so that the "group's" heatmap setting is also remembered
I will wait to test this story again until I hear that it needs testing again.

Changes to update preferences related to heatmap of all selected track committed.
Ready for first level review

Issue 1) Currently, if I color tracks "A" and "B" with "Heatmap Setting 1", and then color tracks "B" and "C" with "Heatmap Setting 2", track "A" also gets "Heatmap Setting 2" applied when it should remain at "Heatmap Setting 1" (it does appear that "Heatmap Setting 1" stays in the Heatmap Editor's memory for that track, though, which is correct.)

I was able to select A, B, apply a color, then select C,D and apply another set of colors and each set retained their respective colors.

Issue 2) It seems that if I apply a heatmap setting to a track, and then select that track and another track and apply a different heatmap setting, the heatmap setting that gets remembered is not necessarily the one that is currently applied. Instead, it seems that the track's "individual heatmap setting" is always remembered, not the "group's heatmap setting".

This is no longer happening, when I apply settings multiple times the available color setting stays the most previous setting I used, even after restarting IGB.

When annotations are first loaded though, a random color settings seems to apply itself, and then I can select and apply my most previous used one after that. I assume this is by design, but not sure what decides the default color that gets loaded

**Edit, the initial color must be unrelated to colorby... Each track retains it's individual color each time it is loaded, so it must be associated with the track itself, and not held somewhere in IGB. Since this is unrelated, I'm moving to 'ready for pull request'

I think this issue may not have been merged yet because I am not seeing Issue #2 (from comment above) as fixed, so I am moving it back to the To-Do column and assigning to Devdatta.

Also, there is an Open Pull Request on this issue.

I copied Devdatta's branch to a new branch on my fork:
https://bitbucket.org/IvoryBlak/integrated-genome-browser/branch/IGBF-1129

I rebased it, and it builds on my machine. (no failing quickload test) : )
I want to test it (for function and too look for any new bugs it might introduce) before we merge it in.
Back when Devdatta was working on this issue, Mason tested it several times and made some really good catches. So I'd like to get Mason to test this as well.

While reviewing the code, I read a comment in code saying "Not good design, need to find better solution". I think this is written by original developer(Devdatta).
I am not sure but this might be the reason Prof. Loraine did not merge this commit an year ago. We should consult her about it.
This functionality requires IGBF-1232 to merge with the master for reviewing and developer testing.
Assigning back to Ivory.

The same comment ("Not good design, need to find better solution" in core/igb/src/main/java/com/affymetrix/igb/action/ColorByAction.java, line 47) is the only downside I have found.
I don't see any cause for concern in the code, and I have tested the app and I haven't been able to break it.

Something I remember and which might help you guys:
I had added that comment because I believed there can be a better way to do color by operations.
While analyzing the code, it felt like original developer (@Sneha: I was not original developer, was just fixing the bug) wanted to make overall options pane and dialogs reusable, but the options data flow, which was expected to be independent of module using it ("color by" in this case) was closely tied to tracks. Also, to manage preferences, this close association was required. So rather than changing entire system it was decided to work with available code and hence I did add that comment.
From what I remember, I had completed development for that bug fix and code was not merged because we were moving to process where a code has to be reviewed by another developer before merging to main repo. The code was ready for review.

Thanks for the clarification!

I think this one commit just got lost in our process and we're trying to get it back into place now.
It's been reviewed by two of us, so I think we can move to the pull request. I'll see if Ann wants us to let Mason take at pass it just to be safe.

Can you (Ivory or Devdatta?) re-base the pull request onto the latest master branch?

I am sorry I have deleted clone from laptop, @Ivory can you do this?
If you need me, I can do this after going home, I am currently in office.

I have rebased this and created a pull request, and reassigned to Dr. Loraine.

It seems that this issue is functioning as expected. The "ColorBy" feature is applying Heatmap Settings and remembering them in a way that is intuitive to the user. After testing, I can confirm that this story is resolved because the two issues mentioned in this story have been addressed and are working as expected:

1. If I color tracks "A" and "B" with "Heatmap Setting 1", and then color tracks "B" and "C" with "Heatmap Setting 2", track "A" also gets "Heatmap Setting 2" applied when it should remain at "Heatmap Setting 1"

2. If I apply a heatmap setting to a track, and then select that track and another track and apply a different heatmap setting, the heatmap setting that gets remembered is not necessarily the one that is currently applied. Instead, it seems that the track's "individual heatmap setting" is always remembered, not the "group's heatmap setting"

Since this issue is resolved and there seem to be no side effects related to this change, it will now be closed.