New commit detected on cfme/5.4.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=3b33b4c0b8ed0158d9a60658caa55295295ef80d commit 3b33b4c0b8ed0158d9a60658caa55295295ef80d Author: Martin Hradil <mhradil> AuthorDate: Mon Nov 9 17:13:19 2015 +0000 Commit: Martin Hradil <mhradil> CommitDate: Mon Nov 9 17:13:19 2015 +0000 DialogRunner#dialog_get_form_vars - handle DateTime field input in random order upstream pr#5259: 0f5bc03 fb7b7a8 b4aa3db backported to 5.4.z Differences from upstream: upstream has #3039 which was not backported to 5.4.z differences in dialog_get_form_vars are mainly about parameter_key => p[0], parameter_value => p[1] and a few omitted cleanups the spec mocks dialog.dialog_tabs instead of dialog.dialog_fields https://bugzilla.redhat.com/show_bug.cgi?id=1277624 .../application_controller/dialog_runner.rb | 30 ++++++++++----- .../application_controller/dialog_runner_spec.rb | 45 ++++++++++++++++++++++ 2 files changed, 65 insertions(+), 10 deletions(-)
New commit detected on cfme/5.4.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=b9c4d36ddac909a997e8e708f8e0e877429faa5a commit b9c4d36ddac909a997e8e708f8e0e877429faa5a Merge: a781ded 3b33b4c Author: Dan Clarizio <dclarizi> AuthorDate: Tue Nov 10 12:22:48 2015 -0500 Commit: Dan Clarizio <dclarizi> CommitDate: Tue Nov 10 12:22:48 2015 -0500 Merge branch 'bz1277624-54' into '5.4.z' DialogRunner#dialog_get_form_vars - handle DateTime field input in random order upstream PR [#5259](https://github.com/ManageIQ/manageiq/pull/5259): 0f5bc03, fb7b7a8, b4aa3db backported to 5.4.z - very unclean cherry-pick :) Differences from upstream: * upstream has [#3039](https://github.com/ManageIQ/manageiq/pull/3039) which was not backported to 5.4.z * differences in dialog_get_form_vars are mainly about parameter_key => p[0], parameter_value => p[1] * and a few omitted cleanups * the spec mocks dialog.dialog_tabs instead of dialog.dialog_fields https://bugzilla.redhat.com/show_bug.cgi?id=1277624 See merge request !386 .../application_controller/dialog_runner.rb | 30 ++++++++++----- .../application_controller/dialog_runner_spec.rb | 45 ++++++++++++++++++++++ 2 files changed, 65 insertions(+), 10 deletions(-)
Martin: It appears that MR 386 was merged. Was there anything else? If not, please place this issue into Post. Thanks!
Should be all, POSTing :)
I'll take this one. A quick look it appears it's just ignoring the time setting altogether.
I rechecked with the 5.4.4.3 build on https://10.16.6.157/miq_request/show/1203r3 and it just doesn't seem to be recognizing any date/time I select. I set it for 10 minutes in the future, click Submit, and check the request. The request shows the current date/time and the request executes immediately. I'll leave the appliance and request above active for a while should you want to take a peek.
Deferring this issue to the 5.4.5 version, since we are less than week away from 5.4.4 release. JohnH okay the deferral.
Jeff, I've just retried on 5.4 and have verified that the value is indeed set properly and is indeed correctly saved into miq_queue. You're mentioning miq_request which leads me to think you're either testing something completely different or have found a related bug further on, which depends on what you're actually trying to do. What I did: 1. create a new dialog+tab+box+ DateTimeControl field, under Automate/Customization 2. create a new custom button (on vm instance) which triggers this dialog 3. go to Vm/Infra/wherever that button is, click it, fill out the datetime control 4. submit 5. check that a new entry is added to miq_queue table, with args= --- - :namespace: SYSTEM :class_name: PROCESS :instance_name: Automation :automate_message: create :attrs: request: dtdt dialog_dt: '2015-12-07T15:32:00Z' :object_type: VmVmware :object_id: 10000000000150 :user_id: 10000000000001 (the dialog_dt is the important bit) Are you doing something fundamentally different?
I wasn't checking the table directly. I was looking at the wrong gui field which had the last update time. Using your steps, the table data is correct. Moving to Verified. for 5.4.4 Thanks
Moved the target release back to 5.4.4 as this is fixed in that version.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-2620.html
*** Bug 1301165 has been marked as a duplicate of this bug. ***