Description of problem: Date Picker and DateTime Picker not returning proper values Version-Release number of selected component (if applicable): 5.10.1 How reproducible: 100% Steps to Reproduce: 1. Create a dialog with a Date Picker/DateTmie picker 2. Make the dialog field dynamic 3. Create a service and add your dialog 4. Order your service Actual results: Notice the date is tomorrow Expected results: Date should be today Additional info: Reproducer: 10.8.196.234 Order service vmware65_item1
Created attachment 1540719 [details] Date Picker and DateTime Picker not returning proper values
So I disagree with the premise of this ticket because it makes no sense to have a datetime picker that picks today, actually. That was initially set to tomorrow because in something like a retirement context, it makes no sense whatsoever to provision a vm that gets immediately retired. So the stated intended behavior of this please had better not be loading with today's date. That's just kinda idiotic. Actual results: Notice the date is tomorrow Expected results: Date should be today I hope not. Can I get someone to reevaluate that for me please? What I do think is wrong is that the date time picker and date picker, when dynamic, don't get the values set correctly by automate. But that's a far different thing than the stated reason this ticket was opened. I see the automate_values_hash method on the dialog running eight times for a single dynamic field, and that seems bad. Also this is pretty clearly a backend issue and probably shouldn't be assigned to Zita.
it is a date Picker with Day + hours and minutes or just Day?
The default, acting as designed behavior of _both_ types of fields, datetimepicker and datepicker, is for the default to be a day ahead of today.
https://github.com/ManageIQ/manageiq/pull/18523
The issue is still reproducible with Timepicker. tested in Version 5.11.0.13.20190705140324_b74c283 Hence failing this BZ Automate method ............... new_date = Time.utc(2019, 07, 02) $evm.object['value'] = new_date
Created attachment 1588691 [details] screenshot timepicker
Unfortunately I'm logging that the automation on this is working as intended now which means this failed QE for a reason that I believe is more a UI issue. The log shows the correct value being set inside the engine: <AEMethod inspectme> herehere: 2019-07-02 00:00:00 UTC The api call on a field refresh correctly returns this: dialog_fields: {date_control_1: "07/02/2019", date_time_control_1: "07/02/2019 00:00"} date_control_1: "07/02/2019" date_time_control_1: "07/02/2019 00:00" Assigning to Harpreet.
Although, I think this ticket should be verified, since the issue was fixed, it's just that we also have a different issue which requires a different ticket.
I have rasied as a different issue https://bugzilla.redhat.com/show_bug.cgi?id=1728964
Verified in Version 5.11.0.13.20190705140324_b74c283
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://access.redhat.com/errata/RHBA-2019:4199