Bug 669729

Summary: default dashboard is blank with new database and clean
Product: [Other] RHQ Project Reporter: Simeon Pinder <spinder>
Component: Core UIAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 4.0.0.B02   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-02 03:18:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 705059, 715334    

Description Simeon Pinder 2011-01-14 10:02:39 EST
Description of problem:
After new database setup the default dashboard is blank.  The menu is displayed correctly(except Dashboard which is not selected). Clicking on other menu items work fine. 

The same behavior was verified with different versions of both Chrome and Firefox.

Issue appears to disappear after using Inventory tab to import a platform. 

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. Do 'clean, install' on master with dbsetup
2. Login to the UI.
3. Dashboard is blank.
4. Use inventory tab to import platform to force dashboard retrieval.
Actual results:
Dashboard empty.

Expected results:
Default dashboard displayed.

Additional info:
-Manually editing the url to display :7080/coregui/CoreGUI.html#Dashboards with (s) seemed to cause successful selection of Dashboard menu item, but still empty.
-F5 refresh does not fix this issue either.
Comment 1 Simeon Pinder 2011-01-16 12:25:56 EST
This is worse than I initially thought. Importing platforms does not fix the Dashboard retrieval issue.

This appears to be a problem in the smartgwt layer itself triggered by logic in the Dashboard page. 

I rolled back the smartgwt version to 2.2.RHQ1 and 2.2.RHQ2 and was still not able to fix this issue.

We'll  have to find out which Dashboard elements or logic is causing this error and rewrite/re-implement it.

It is also important to do a mvn clean of the coregui element before building to successfully clean out the old javascript elements in between tests.  Without clean, junk accumulates from previous builds masking the issue.
Comment 2 Jay Shaughnessy 2011-01-17 17:54:26 EST
After a completely clean build and new DB I could not reproduce this issue. I'm using commit 41a92e1.

If you tried to get to CoreGUI via portal war's redirect there was a problem, the "#Dashboard" url was incorrect. This is corrected now in commit 0109deb7b7f70712dbfa05e6413d0222844f5fc6.

Simeon, any additional follow up?  I think this can be closed.
Comment 3 Simeon Pinder 2011-01-17 20:18:30 EST
I am also able to build the Dashboard without the earlier reported problem this morning as well without any changes to the source on either of the two boxes that were used to verify the earlier problem.  As there were no changes to source that could cause spontaneous recovery I believe one or some combination of the following can be used to explain the described behavior: 

i)the dependencies hosted by the maven repositories must have been affected by the recent cleanup for the git repositories that happened this weekend to improve clone times.
ii) some communications problem affected/corrupting dependencies or build processes of two separate linux boxes on my local network were at fault.
iii) my use of mvn3 -T {N} on multi-core boxes/builds contributed to a repeatable corruption causing the described issues.

In any event, the blocking issue around Dashboard builds appears to have been resolved or is being reliably avoided.

This issue can be closed.
Comment 4 Jay Shaughnessy 2011-05-23 11:25:04 EDT
This was fixed a while ago.  Setting for QA in the current sprint.
Comment 5 Mike Foley 2011-05-24 09:19:30 EDT
verified through clean install.
Comment 6 Heiko W. Rupp 2013-09-02 03:18:47 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.