-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dialog field loading/refresh refactor to fix automate delays #17329
Dialog field loading/refresh refactor to fix automate delays #17329
Conversation
0bc3b9d
to
9c7dadf
Compare
@miq-bot add_label wip |
@d-m-u Please review |
691582b
to
df6c73e
Compare
df6c73e
to
dac46a2
Compare
Checked commits eclarizio/manageiq@956d9b5~...dac46a2 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
@miq-bot remove_label wip Un-WIP-ing and updated the top comment with more context. Would be nice to have multiple reviews on this as well! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eclarizio Looks good.
We have been testing heavily on this PR and at this point not seeing issues with the automate methods running extra runs. Nice performance improvements overall. 👍 |
…_sev2 Dialog field loading/refresh refactor to fix automate delays (cherry picked from commit c719d7f) https://bugzilla.redhat.com/show_bug.cgi?id=1572716 https://bugzilla.redhat.com/show_bug.cgi?id=1572711
Gaprindashvili backport details:
|
This PR is intended to fix an issue where the automate methods for dialog fields were running multiple times for seemingly no reason. Upon loading of a dialog (via custom button click or service catalog order, for example), sometimes dialog fields would also run in a seemingly random order. We figured out that due to the way the
#value
method was written for some of the dialog field types, those would call the automate method first, before the method#initialize_with_values
was called.However,
#initialize_with_values
was kind of misnamed, as it was really more about just establishing values for the context in theResourceActionWorkflow
. So, I've renamed that method and adjusted the logic around when it gets called.Another large change is that the
DialogFieldSerializer
was making a call to the automate methods because if a field was dynamic it would try to get the values for that field. However, I don't think this should be the job of the serializer, it should simply serialize what it's given. So if something needs to update, it now does so before calling into the serializer.For a refresh,
#initialize_with_values
was closer to the correct name of describing what needed to be done, but I also added#load_values_into_fields
for when the dialog needs to refresh. Note that the logic to go into this method depends upon an option that gets passed in from this API PR.This PR touches all of the
DialogField
types and theDialog
model itself, as well as theResourceActionWorkflow
, which are (obviously) how every single dialog do their thing. Therefore, this PR should undergo a much more rigorous test before merging. QE is involved in helping test this PR as well.Needs ManageIQ/manageiq-api#365 to be merged first.
https://bugzilla.redhat.com/show_bug.cgi?id=1559757
https://bugzilla.redhat.com/show_bug.cgi?id=1571000