Bug 1614436 - Triggered Refresh Still Occurs for Dialog After Changing Type to Static
Summary: Triggered Refresh Still Occurs for Dialog After Changing Type to Static
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: GA
: 5.10.0
Assignee: Roman Blanco
QA Contact: Niyaz Akhtar Ansari
URL:
Whiteboard:
Depends On:
Blocks: 1632769
TreeView+ depends on / blocked
 
Reported: 2018-08-09 14:53 UTC by myoder
Modified: 2021-12-10 16:57 UTC (History)
9 users (show)

Fixed In Version: 5.10.0.18
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1632769 (view as bug list)
Environment:
Last Closed: 2019-02-12 16:49:55 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description myoder 2018-08-09 14:53:43 UTC
Description of problem:

Automate methods are via triggered refreshes for elements that are no longer dynamice.

Given 2 dialog elements, A and B.  B is a dynamic dialog, and A is configured to trigger a refresh on B.  Then, if we change dialog B to be static, A should no longer trigger a refresh on B.  However, viewing the automation.log, we still see the automate method that was associated with B is being executed.  Note, that when editing the element A in the UI, element B is no longer shown in the list of elements to trigger a refresh for.

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

How reproducible:
always

Steps to Reproduce:
1. Create a dialog with 2 elements, A and B.
2. B is dynamic, and a triggered refresh should be executed for B whenever A changes/refreshes.
3. Edit element B so that it is now static, and should no longer be triggered to refresh
4. Use the dialog and refresh element A.

Actual results:
automation.log will show that the method that was associated with element B is still being executed.

Expected results:
The method that was associated with element B should not be run.

Additional info:
I have recreated this on 10.13.153.115 default credentials.  There is a custom button group for VM and Instance named Yoder which has a custom button 'yoder_test' that uses a service dialog also named 'yoder_test'.  In this service dialog the 2 elements that show this behavior are named Area and Box.  Both Area and Box started as dynamic, and Area was configured to trigger a refresh on Box.  I then changed Box to be a static element.  If you order the button 'yoder_test' and refresh the Area element, you will see that the Box method is still being run in the automation.log:


[----] I, [2018-08-09T10:37:21.492205 #29641:ea1460]  INFO -- : <AEMethod [/Yoder/Dialog/Methods/box]> Starting 
[----] I, [2018-08-09T10:37:21.787202 #29641:ea12f8]  INFO -- : Updated namespace [Dialog/Methods/drop  Yoder/Dialog]
[----] I, [2018-08-09T10:37:21.801469 #29641:ea12f8]  INFO -- : Invoking [inline] method [/Yoder/Dialog/Methods/drop] with inputs [{}]
[----] I, [2018-08-09T10:37:21.803531 #29641:ea12f8]  INFO -- : <AEMethod [/Yoder/Dialog/Methods/drop]> Starting 
[----] I, [2018-08-09T10:37:22.357948 #29641:ed10ac]  INFO -- : <AEMethod box> ##################################################
[----] I, [2018-08-09T10:37:22.359439 #29641:ed10ac]  INFO -- : <AEMethod box> ############# BOX  DIALOG ########################
[----] I, [2018-08-09T10:37:22.360733 #29641:ed10ac]  INFO -- : <AEMethod box> ##################################################
[----] I, [2018-08-09T10:37:22.388602 #29641:ea1460]  INFO -- : <AEMethod [/Yoder/Dialog/Methods/box]> Ending

Comment 3 drew uhlmann 2018-09-05 14:06:01 UTC
Hey Yoder! Could you do me a huge favor please and see if https://github.com/ManageIQ/manageiq/pull/17946 adequately addresses this issue?

Comment 4 drew uhlmann 2018-09-05 19:24:27 UTC
While I'm working on getting that merged and passing tests, the workaround for this issue is to fix the dialog. The dialog can be exported, the now-static fields removed from the list of field responders, and then the re-imported dialog should behave as expected.

Comment 7 drew uhlmann 2018-09-11 15:20:52 UTC
Hey Yoder! Thanks for checking for me. I didn't run into the issue you listed but the root cause of this bug is that we're not addressing the removal of the DialogFieldAssociations that are no longer valid. My PR won't work as it doesn't fix that, so please disregard. 

Hey Roman! I'm assigning this to you for the time being, please feel free to give it back because it could be either backend or UI. The issue is that when dynamic fields are changed to be static in the UI, any DialogFieldAssociation with that field as a responder also need to be destroyed. We're not currently doing this.

Comment 8 Roman Blanco 2018-09-18 11:50:13 UTC
Fixed in https://github.com/ManageIQ/ui-components/pull/347

Comment 9 CFME Bot 2018-09-25 12:14:40 UTC
New commit detected on ManageIQ/ui-components/master:

https://github.com/ManageIQ/ui-components/commit/3b7be844e4ec9f86e7d30e66c6ee75ea33f5c563
commit 3b7be844e4ec9f86e7d30e66c6ee75ea33f5c563
Author:     Roman Blanco <rblanco>
AuthorDate: Fri Sep 14 07:32:16 2018 -0400
Commit:     Roman Blanco <rblanco>
CommitDate: Fri Sep 14 07:32:16 2018 -0400

    Update dynamic fields responders after change

    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1614436

 src/dialog-editor/components/abstractModal.ts | 1 +
 src/dialog-editor/components/box/box.html | 1 +
 src/dialog-editor/components/modal-field/field.html | 1 +
 src/dialog-editor/components/modal/modalComponent.ts | 16 +
 4 files changed, 19 insertions(+)

Comment 11 Niyaz Akhtar Ansari 2018-10-30 08:55:16 UTC
Verified in Version 5.10.0.21.20181023151612_4c11b0d


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