Bug #13352
Dashboard widget rows are loaded in reverse order
Description
See this on a develop production install on centos7 . Screenshot attached.
Related issues
Associated revisions
fixes #13352 - order dashboard widgets by ID for consistency
When a user's dashboard widgets are seeded, they receive default row and
column positions of 1, so gridster organises the widgets in the order
they are defined in the view - which before this change, is up to the
database and can vary in order.
Ordering widgets by ID ensures the widgets will start in the order they
were added to the database in (which in turn is from the widget
registration order). If a user saves the dashboard, the saved row/col
values take precedence.
(cherry picked from commit 076608d7629efb4e50de3667d1c26e63fe092553)
History
#1
Updated by Dominic Cleal almost 4 years ago
- Legacy Backlogs Release (now unused) set to 71
Appears to be a recent regression, looks fine on 1.10.
#2
Updated by Ohad Levy almost 4 years ago
- Related to Bug #13706: Dashboard items are on top added
#3
Updated by Dominic Cleal over 3 years ago
- Status changed from New to Assigned
- Assignee set to Dominic Cleal
#4
Updated by The Foreman Bot over 3 years ago
- Status changed from Assigned to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/3341 added
#5
Updated by Dominic Cleal over 3 years ago
Some additional data from an installation suffering from this bug. When rendering the dashboard with a new user's seeded widgets, all rows and cols are 1, but the order of widgets returned from the database is the reverse of what you'd expect:
irb(main):008:0> User.first.widgets => #<ActiveRecord::Associations::CollectionProxy [#<Widget id: 12, user_id: 3, template: "distribution_widget", name: "Distribution chart", data: {}, sizex: 6, sizey: 1, col: 1, row: 1, hide: false, created_at: "2016-03-17 11:12:43", updated_at: "2016-03-17 11:12:43">, #<Widget id: 11, user_id: 3, template: "reports_widget", name: "Report summary", data: {}, sizex: 6, sizey: 1, col: 1, row: 1, hide: false, created_at: "2016-03-17 11:12:43", updated_at: "2016-03-17 11:12:43">, #<Widget id: 10, user_id: 3, template: "status_chart_widget", name: "Status chart", data: {}, sizex: 4, sizey: 1, col: 1, row: 1, hide: false, created_at: "2016-03-17 11:12:43", updated_at: "2016-03-17 11:12:43">, #<Widget id: 9, user_id: 3, template: "status_widget", name: "Status table", data: {}, sizex: 8, sizey: 1, col: 1, row: 1, hide: false, created_at: "2016-03-17 11:12:43", updated_at: "2016-03-17 11:12:43">]>
IDs are actually descending, and so the dashboard ends up "backwards", in the opposite order to the default widget registration order.
#6
Updated by Dominic Cleal over 3 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 076608d7629efb4e50de3667d1c26e63fe092553.
#7
Updated by Ohad Levy over 3 years ago
- Bugzilla link set to 1325644
fixes #13352 - order dashboard widgets by ID for consistency
When a user's dashboard widgets are seeded, they receive default row and
column positions of 1, so gridster organises the widgets in the order
they are defined in the view - which before this change, is up to the
database and can vary in order.
Ordering widgets by ID ensures the widgets will start in the order they
were added to the database in (which in turn is from the widget
registration order). If a user saves the dashboard, the saved row/col
values take precedence.