Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 669729 - default dashboard is blank with new database and clean
default dashboard is blank with new database and clean
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
Unspecified Unspecified
high Severity high (vote)
: ---
: ---
Assigned To: Jay Shaughnessy
Mike Foley
Depends On:
Blocks: jon3-sprint1 715334
  Show dependency treegraph
Reported: 2011-01-14 10:02 EST by Simeon Pinder
Modified: 2013-09-02 03:18 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-02 03:18:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.