Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1519275 - Elements in order service screen don't have any unique attribute value
Summary: Elements in order service screen don't have any unique attribute value
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS
Version: 5.9.0
Hardware: All
OS: All
high
medium
Target Milestone: GA
: 5.10.0
Assignee: Chris Hale
QA Contact: Dmitry Misharov
URL:
Whiteboard: ui
Depends On:
Blocks: 1530836
TreeView+ depends on / blocked
 
Reported: 2017-11-30 14:12 UTC by Dmitry Misharov
Modified: 2018-06-21 21:12 UTC (History)
8 users (show)

Fixed In Version: 5.10.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1530836 (view as bug list)
Environment:
Last Closed: 2018-06-21 21:12:51 UTC
Category: Bug
Cloudforms Team: CFME Core


Attachments (Terms of Use)

Description Dmitry Misharov 2017-11-30 14:12:21 UTC
Description of problem:
QE automation test suite cannot find elements which don't have some unique locator like it's implemented here:
<input ng-model="vm.dialogField.default_value" ng-disabled="vm.dialogField.read_only || vm.inputDisabled" ng-change="vm.changesHappened()" ng-blur="vm.validateField()" ng-model-options="{debounce: {'default': 500}}" class="form-control ng-pristine ng-untouched ng-valid ng-not-empty" uib-tooltip="" value="localhost" type="text">

There is no "id", "name" or another attribute which helps to locate this input on the page. 

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

How reproducible:
Always

Steps to Reproduce:
1. Create some service catalog and pick some service dialog there.
2. Open "Order Service" screen.

Actual results:
Service dialog inputs, selects and other elements don't have unique, not ambiguous locators.

Expected results:
Elements should have some attribute(s) with values which allow to find these elements on the page.

Comment 2 Martin Povolny 2017-12-01 20:40:44 UTC
Dmitry, for sake of clarity, can you be more specific about the requirements for the attribute?

You wrote:
> There is no "id", "name" or another attribute which helps to locate this input on the page. 

So you want something unique. Guess it should not be random or can it be random? Should it have some relation to the types of fieds, or just something sequentially numbered?

Please, write don't what would be the best for your tests and what would be sufficient.

Thank you!

Comment 3 Martin Povolny 2017-12-02 07:36:01 UTC
> Please, write don't

Please, write down ;-)

Comment 4 Dmitry Misharov 2017-12-04 09:58:30 UTC
We'd like to have the "id" attribute with the value that reflects a name of a respectful label. For example, if "input" element is supposed to be filled by some hostname it should have the "id" attribute with value "hostname". We'd like to have such attributes for any element which requires the user interaction: inputs, selects, dropdowns, checkboxes, switches, buttons and so on.

Comment 5 Chris Hale 2017-12-06 18:02:59 UTC
In looking at it, I worked and can add an id attribute without too much trouble.  I can't however do a simple field naming like the example you provided above.  Id attributes need to be unique and not start with a number and contain no spaces.  I can do something like "dialog_10000000003034".  This id number at the end is the databases ID for the dialogs particular field.  This should allow you to hone in and do DOM queries based on that. Let me know if that works for you.

Comment 6 Chris Hale 2017-12-06 19:01:39 UTC
Please disregard my last comment.  I looked closer at our response for dialog fields and it appears as though I can use the "name" field that is used when creating a dialog field.  I will go ahead and implement with this strategy. If you run into issues after implementation we can always open another PR.

Comment 7 Chris Hale 2017-12-06 19:01:47 UTC
Please disregard my last comment.  I looked closer at our response for dialog fields and it appears as though I can use the "name" field that is used when creating a dialog field.  I will go ahead and implement with this strategy. If you run into issues after implementation we can always open another PR.

Comment 8 Chris Hale 2017-12-06 19:18:18 UTC
GH PR https://github.com/ManageIQ/ui-components/pull/214


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