Bug 1344632 - Default value of TexBox does not correspond to its type
Summary: Default value of TexBox does not correspond to its type
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.6.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: GA
: cfme-future
Assignee: Greg McCullough
QA Contact: Jiri Stefanisin
URL:
Whiteboard: ui:automate
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-10 08:34 UTC by Jiri Stefanisin
Modified: 2017-03-16 01:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-16 01:33:45 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)

Description Jiri Stefanisin 2016-06-10 08:34:00 UTC
Description of problem:
When creating new TextBox in Dialog, type is set to Integer by default but the default value in TextBox remains "".


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Create Dialog with dialog field TextBox and set data type as integer for this field
2. Create a Catalog Item and assign the Dialog created in step 1
3. Go Service Catalog and order a service, when submitting the dialog, it should do default validation on data type for Textbox fields.

Actual results:
When type is set to Integer, default value should be set to 0

Expected results:


Additional info:
Found while testing https://bugzilla.redhat.com/show_bug.cgi?id=1278170

Comment 2 Greg McCullough 2016-06-10 13:03:12 UTC
Erik - I think the important change here is that the edit field needs to default to the type of string.  For the integer type I recall that an empty field will pass nil which is valid and can be interrupted in the scripting layer if needed.  If that is not correct then it likely should default to an integer value when the data type is changed.

Comment 4 Jiri Stefanisin 2017-02-20 12:23:54 UTC
Hello,
i was not aware of this behavior being intended. May I see the specification?


Note You need to log in before you can comment on or make changes to this bug.