Bug 1731017 - Moving reports to a different menu does not work as expected
Summary: Moving reports to a different menu does not work as expected
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Reporting
Version: 5.11.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.11.0
Assignee: drew uhlmann
QA Contact: Parthvi Vala
Red Hat CloudForms Documentation
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-18 06:59 UTC by Parthvi Vala
Modified: 2019-12-13 14:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-12-13 14:58:10 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github 9219 0 None None None 2019-08-19 13:58:17 UTC

Description Parthvi Vala 2019-07-18 06:59:34 UTC
Description of problem:
Moving reports to a menu does not work as expected. Read steps to reproduce for a better understanding of the problem.

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

How reproducible:

Steps to Reproduce:
1. Create a custom report or copy an existing report.
2. Move the custom report to 'Tenants > Tenant Quotas' menu in the user's current group
3. See if the report is available under 'Tenants > Tenant Quotas'.
4. Delete the custom report.
5. See if the report is available under 'Tenants > Tenant Quotas'.
6. Add a new report with the same menu_name.
7. See if the report is available under 'Tenants > Tenant Quotas'.

Actual results:
3. Report is visible.
5. Report is not visible
7. Report is visible.     <-----

Expected results:
3. Report must be visible.
5. Report must not be visible.
7. Report must not be visible.

Additional info:
The issue has been in existence since 5.9. This problem probably arises because a new report is created with the same menu_name.

5.9 Reference BZ - https://bugzilla.redhat.com/show_bug.cgi?id=1676638

Comment 2 drew uhlmann 2019-07-23 20:05:47 UTC
Incidentally, in case anyone's looking at this ticket, LJ's right about it, and it's a UI issue. The same report can have multiple nodes in the tree in some cases.

Comment 3 Yuri Rudman 2019-07-25 18:21:40 UTC
I think it is back-end bug: report's menu structure kept in miq_group#settings which is Hash of report names. 
When we delete custom report we are not updating that field and name of deleted custom report still present in miq_group#settings.
UI does not show that since actual report deleted. When new custom report with same name created - it would be shown in the old place.

There is work around of this issue: after/before deleting custom report remove it from list of reports available for group by using "Edit report Menus"

Comment 4 drew uhlmann 2019-07-30 18:29:17 UTC
I'm confused because loading all MiqGroup settings after the destroy on https://github.com/ManageIQ/manageiq-ui-classic/blob/e7a3be000841c4b6f15f8d2a88a7c3dcf5e5939d/app/controllers/report_controller/reports.rb#L78, the settings all appear nil: 

[----] D, [2019-07-30T14:25:56.771656 #48307:3ffa4c9752f8] DEBUG -- :    (0.4ms)  SELECT "miq_groups"."settings" FROM "miq_groups"
=> [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil]

Comment 6 CFME Bot 2019-08-07 22:37:40 UTC
New commit detected on ManageIQ/manageiq-ui-classic/ivanchuk:

commit b6888e07ec6d856944233ec45618f4a8ca79638e
Author:     Martin Povolny <mpovolny@redhat.com>
AuthorDate: Wed Aug  7 10:06:45 2019 -0400
Commit:     Martin Povolny <mpovolny@redhat.com>
CommitDate: Wed Aug  7 10:06:45 2019 -0400

    Merge pull request #5950 from d-m-u/fixing_settings_hash_of_miq_group

    Remove report names from group settings hash when reports are deleted

    (cherry picked from commit 4cee794225b186ee70447013f9df25009de5ebef)


 app/controllers/report_controller/reports.rb | 12 +-
 spec/controllers/miq_report_controller/reports_spec.rb | 15 +
 2 files changed, 25 insertions(+), 2 deletions(-)

Comment 7 Parthvi Vala 2019-08-19 07:04:46 UTC
FIXED. Verified on

Thanks for fixing this.

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