-
Notifications
You must be signed in to change notification settings - Fork 91
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
VM custom button dialog - use the VM instead of the parent service #1542
Conversation
Triggering a VM-based custom button on a Service's VM Resource causes the right dialog to appear.. But the inital data assumes the associated resource is the service, not the VM. Subsequent field refresh requests and submit already use the VM, but the initial load was missed in #1022. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1687061
Have a Custom Button for VMs, associated with a service, which uses the VM's data to populate dropdown options (see the bz for exact steps). Go to My Services does get /api/service_dialogs/110?expand=resources&attributes=content&resource_action_id=6572&target_id=4&target_type=service after this, it does |
@eclarizio do you have a setup to review/test this? |
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.
@h-kataria Unfortunately, I don't have a current environment to test this, but from what @himdel is saying about how it works, this does look like it will fix the issue.
@himdel Can you add a spec for this? It doesn't look like the initialization test doesn't have a vmId
in the definition so it will never hit this code to verify.
Thanks @eclarizio, working on a spec now... As for the environment, yeah, it's not exactly trivial, this should help: So, steps to reproduce - setup:
Then,
|
Tests should be ready :) |
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.
I think one more spec to be added, but otherwise it's looking good 👍
id: 213 | ||
} | ||
|
||
it('sends target_type=vm service dialog query on init', (done) => { |
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.
I think we're still missing the spec for when the vmId
doesn't exist, right? There are still cases where the service dialogs endpoint is going to request with the target_type
of 'service'
and the target_id
with that service's id.
I guess maybe this spec didn't exist before, but I think it needs to be added now that we have these two different calls happening.
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.
Good catch 👍. The tests should probably be reorganized a bit to be more symmetrical, and looks like we have some SUI test inconsistencies (3 tests randomly in jest not karma), can't use object spread there, etc.
But for now, I just added a similar test for init without vmId
:).
…Id and right target for service dialog query as opposed to always serviceId had to wrap the rest in another describe, to prevent beforeEach from initializing the controller before the right setup and pulled out a few of the constants up, to DRY up the tests a bit
Checked commits https://github.com/himdel/manageiq-ui-service/compare/41a30d5d3a34c76ecb9d9b19ec7b5351f7fc6158~...8d8c02de972ce7013cd4fe842d0daef5c25c57d2 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
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.
Nice 🎉
VM custom button dialog - use the VM instead of the parent service (cherry picked from commit 61c583c) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1722817
Hammer backport details:
|
Triggering a VM-based custom button on a Service's VM Resource causes the right dialog to appear..
But the inital data assumes the associated resource is the service, not the VM.
Subsequent field refresh requests and submit already use the VM, but the initial load was missed in #1022.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1687061