Data views do not seem to work after selecting 'Alternate View'

[Emily]

Firefox and IE6:
- After selecting 'Alternate View', it is not possible to select another data view from the menu. The yellow error box 'The website is loading content, please try this action again.' appears, and need to go back to 'Home' to be able to access data again.

[Philippe Boucher (boucherp)]

Marking this bug as a duplicate of bug #496535 - My gut feeling is that it's the same underlying problem (any other connection to the webapp through the client fails after this - you need to click on the home link or click on reload in order to restore the connection)

[Philippe Boucher (boucherp)]

Turns out this is not a duplicate - we have a workaround that Knut and Philippe found, which when tested doesnt actually fix the metadata display problem for indicator descriptions.

[Philippe Boucher (boucherp)]

Here's the code workaround that we've found - by stepping through the code, we see that after displaying an alternate view, the variable isFlexReady is never reset from false, so no other accesses work after that - if we go to the function changeIndicatorAlternateView() in Navigation.js and add the command setIsFlexReady(true) at the end of the function, then it works - controls are displayed and other views can be accessed, however, we still have the issue that metadata does not appear unless the page is reloaded.
It is unclear who calls the function setIsFlexReady in the general case - we find no calling reference to it in the code and the stack display in firebug does not show a caller for it either.
We havent checked in this line into StarTeam - hardwiring the flex status to ready regardless of what's going on does not seem to be a correct fix, so we're handing this back to T4Bi to see what they come up with based on this.

[Philippe Boucher (boucherp)]

 duplicate no

[Philippe Boucher (boucherp)]

This problem was fixed by updating the GlobalHealthObservatory.xml file (provided by Steve). Discrepencies in the OLAP cube ultimately cause the user interface to fail because flags like isFlexReady do not get set back to what is required for the UI to run correcly. If these flags are forced, then the UI works - we probably need to look at how the UI code handles error conditions in a future release.
xml file is in the repo, setting to fix-committed and we've removed the setIsFlexReady(true) hack