Bug 1685266
| Summary: | Service Dialog Date/DateTime Picker dynamic dialog values not displayed. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | William Fitzgerald <wfitzger> | ||||||
| Component: | UI - OPS | Assignee: | Harpreet Kataria <hkataria> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Niyaz Akhtar Ansari <nansari> | ||||||
| Severity: | medium | Docs Contact: | Red Hat CloudForms Documentation <cloudforms-docs> | ||||||
| Priority: | medium | ||||||||
| Version: | 5.10.1 | CC: | bmidwood, dmetzger, duhlmann, hkataria, lavenel, mpovolny, nansari, obarenbo, simaishi, tfitzger | ||||||
| Target Milestone: | GA | ||||||||
| Target Release: | 5.11.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 5.11.0.1 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-12-12 13:36:02 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | Bug | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | CFME Core | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
William Fitzgerald
2019-03-04 20:07:03 UTC
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. 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 |