sap.m.SelectDialog clear/confirm button should be enabled in single selection mode

[zypA13510]

OpenUI5 version: 1.60/latest

Browser/version (+device/version): Chrome v73 on Ubuntu (desktop)
Any other tested browsers/devices(OK/FAIL): not tested

URL (minimal example if possible): http://jsfiddle.net/zypA1310/L5cx4fut/

Steps to reproduce the problem:

1. Run the above example (SelectDialog with showClearButton=true and multiSelect=false)
2. Click on the value help button

What is the expected result?
In the opened dialog, there is some way to clear the content inside Input, either the clear button or by clicking confirm with an empty selection.

What happens instead?
In the opened dialog, the clear button is shown but disabled. Confirm button is not shown.

Additional information:
According to the doc, this is the intended way to clear value from Input with valueHelpOnly=true:

We recommended enabling of the Clear button in the following cases, where a mechanism to clear the value is needed: In case of single selection mode(default mode) for Select Dialog and rememberSelections is set to true. Clear button needs to be enabled in order to allow users to clear the selection. In case of using sap.m.Input with valueHepOnly^[sic] set to true, Clear button could be used for clearing selection. In case the application stores a value and uses only Select Dialog to edit/maintain it.

Related: #898.

[TeodorTaushanov]

Hi,

Thank you for sharing this finding. I've created an internal incident 1970047730. The status of the issue will be updated here in GitHub.

Regards,
Teodor

[niyap]

Hello @zypA13510 ,

Thank you for ticket. That is the expected behavior of the control.
You could clear your selection when singleSelection and valueHelpOnly are used, but to achive this, you have to adjust the application logic.
Here is a simple sample, how that could be achived: http://veui5infra.dhcp.wdf.sap.corp:8080/demokit/#/sample/sap.m.sample.SelectDialog/preview
Look at the last sample, where the scenario is the same as the one described by you.

Kind Regards,
Niya

[zypA13510]

@niyap
Hello Niya, thanks for your response. Unfortunately, I'm unable to open the link you provided. From the CDN distribution of demo kit (which I believe to be the same?), I can see the last sample. However, after clicking the clear button, there is no way to submit the dialog, the confirm button is not appearing due to it being single selection mode. I'm not sure if I missed anything.

I've also looked into the implementation and provided what I believed to be a fix in the PR.

[niyap]

Hello @zypA13510 ,

Yes, I got it. There was a little mistake in our sample, so we corrected it and it will be available with the next release.
The confirmation button is available in multi selection mode. But you could handle the discussed scenario with clearing the value on value help close. If there is no selected item, on pressing the "Cancel" button, just reset the value of the input field.

Regards,

[zypA13510]

@niyap
But then, it would be very strange behavior, wouldn't it? When a user press "cancel", they usually expect whatever changes they have made in this dialog to be discarded instead of being committed.

Also, from the UX guideline:

Once users select an entry, the select dialog is closed and the selected entry is taken over. If applicable, the entry is displayed in the field from which the dialog was triggered.

IMHO, clearing the entry should be considered the same as "selecting" in the context of single selection mode, thus the dialog should have submitted itself when the clear button is pressed, instead of clear+cancel.

All in all, I'd say clear+cancel is not a very elegant solution to this issue. Rather, I suggest that either: the user press clear, then ok (needs to be displayed in single selection), or the user press clear and the dialog submits itself (in single selection mode).

[niyap]

Hello @zypA13510,

Thank you for your reply and your point of view!

We discussed with the UX designers, both the current behavior, your proposals and other possible solutions for that use case.
As a result, we took the decision to handle that as a feature request.
In that way, all the possible solutions will be evaluated.
We could not commit that the behavior would be changed for sure, since it would be evaluated and the desicion will be made after that.

Kind Regards,
Niya

[flovogt]

This enhancement request is covered in FIORITECHE1-3484 and FIORIDESIGN-614.