Manageiq: Add UI to provide additional parameters after button press

[pilhuhn]

In #8210 I implemented that via a jQuery prompt() that was deemed a bad idea.

8210 contains though a pretty good discussion on how to implement that going forward.

Once this is done, we can take the code from https://github.com/ManageIQ/manageiq/pull/9465 and add the timeout to operations like 'suspend' that allow to pass a timeout.

@miq-bot add_label ui, providers/hawkular
@abonas

[abonas]

@miq-bot assign @mtho11

[abonas]

@miq-bot add_label enhancement

[mtho11]

Current server suspend option with standard confirm dialog box:

To be replaced by PatternFly style custom dialog box with Timeout parameter:

[abonas]

@mtho11 looks great.
I suggest :

1. mentioning timeout's time units in the dialog so it will be crystal clear to the user. (5 seconds? minutes? ms? etc.)
2. is value validation planned in frontend/backend? (input that is not letters, value that is not between X-Y, what happens when timeout is zero)

[pilhuhn]

We should also shoot (but I think I mentioned that to Mike already) allow for more than one property here. E.g. stop/shutdown/restart is the same underlying code, but with different timeouts and also a boolean 'restart'.

[abonas]

We should also shoot (but I think I mentioned that to Mike already) allow for more than one property here. E.g. stop/shutdown/restart is the same underlying code, but with different timeouts and also a boolean 'restart'.

@pilhuhn not sure I follow the "different timeouts" part - timeout is an open field where user can input any timeout. Also, what is the boolean restart that you mention? where should it be available and in which use case?

[pilhuhn]

What I mean is:
Stop = dmr-operation 'shutdown', timeout=0, restart=false
Shutdown = dmr-operation 'shutdown', timeout="ask user", restart=false
Restart = dmr-operation 'shutdown', restart=true, timeout=0 or "ask user"
So all 3 menu options call the same dmr operation on the agent, but with different parameters.
If the box allows to input timeout & restart-bool, then we can have all 3 use cases from one button.

It can make usability sense to still keep the operations with restart=true on a different button than those with restart=false

[abonas]

What I mean is:
Stop = dmr-operation 'shutdown', timeout=0, restart=false
Shutdown = dmr-operation 'shutdown', timeout="ask user", restart=false
Restart = dmr-operation 'shutdown', restart=true, timeout=0 or "ask user"
So all 3 menu options call the same dmr operation on the agent, but with different parameters.
If the box allows to input timeout & restart-bool, then we can have all 3 use cases from one button.

I think this will be too confusing for users. To understand that restart is actually shutdown but with restart=true and with no timeout, for example. Too much details imo.
On the backend side it makes sense to unify the code.

It can make usability sense to still keep the operations with restart=true on a different button than those with restart=false

[pilhuhn]

On 11 Jul 2016, at 10:44, abonas wrote:

I think this will be too confusing for users. To understand that
restart is actually shutdown but with restart=true and with no
timeout, for example. Too much details imo.

Well. Restart should get a timeout too, as the timeout determines
how much time currently active connections still have to finish.

But ok Mike: timeout alone is fine.

[mtho11]

The validations could get a bit complicated considering a different domain for each field type. I'm thinking this is an add-on PR. @abonas is that satisfactory?

[mtho11]

We will need to specify units as well then for each option (or optionally none). Is that alright @pilhuhn?

[mtho11]

I guess we don't really have any specifications for this screen? Which feels strange for a product feature. Is there UxD designs for this?

[abonas]

I guess we don't really have any specifications for this screen? Which feels strange for a product feature. Is there UxD designs for this?

adding @jdoyleoss and @catrobson for this part

[abonas]

We will need to specify units as well then for each option (or optionally none). Is that alright @pilhuhn?

@pilhuhn @mtho11 shouldn't time unit be the same for all operations that require a timeout input?

[abonas]

The validations could get a bit complicated considering a different domain for each field type. I'm thinking this is an add-on PR. @abonas is that satisfactory?

not sure I follow the complicated validations for each field type part - can you please clarify?
timeout is a single field that should accept numbers - what am I missing? :smiley:

[pilhuhn]

Timeout is in seconds, which we can just add as description. Validation is certainly a bonus. We do not need to to save the world though.
And for UxD - let's get that in as is. And then re-style later if needed at all.

[abonas]

Timeout is in seconds, which we can just add as description. Validation is certainly a bonus. We do not need to to save the world though.

not saving the world, but to check that timeout is not "abc" is basic and expected imo. not sure how backend would behave in that case- it can also potentially crash on miq/ruby gem/hawkular side.

And for UxD - let's get that in as is. And then re-style later if needed at all.

[catrobson]

Agreed that units will at least make this consumable for the short term. In the longer term I would probably want to see something that allows users to input in units that make sense for them (UI allows them to put in 10, then select "minutes" from a dropdown) and we can translate that back into seconds for them. Also, I would want to look at the whole flow for this operation (where do I get this dialog from, what use cases might the user actually be working from) to make sure we're really meeting there needs.

[pilhuhn]

We start making an elephant out of a fly.
Let's get this done as is. And then later refine.

[mtho11]

Here is the demo of validation:

[catrobson]

Any chance we can give an error message as part of the validation letting the user know what a valid range would be, right now we're leaving them to guess what numbers are valid which can be frustrating. Here's the PatternFly styling for within a modal with error: http://www.patternfly.org/pattern-library/forms-and-controls/forms/#_

[abonas]

Any chance we can give an error message as part of the validation letting the user know what a valid range would be, right now we're leaving them to guess what numbers are valid which can be frustrating. Here's the PatternFly styling for within a modal with error: http://www.patternfly.org/pattern-library/forms-and-controls/forms/#_

I agree. @mtho11 also, perhaps the dialog can be made less wide? it's just one numeric field, not that of a large input, so I think it will look better more compact.
@catrobson an additional difference between the above and pf style, is that here the buttons become disabled if something's wrong (I like it that way, it is also "guarding" from user errors) while in pf example they don't look disabled - is that the case for pf or it's a wrong screenshot?

[abonas]

@mtho11 one more thing - the screenshots are very helpful, however they belong better in a PR that solves this issue. Please raise the PR (totally fine to mark as WIP if not ready for review/getting merged), and attach the screenshots there. it will also help others to learn how to do it / @pilhuhn to test it even if not 100% ready.

[catrobson]

Yes, we don't normally disable the submit button in PatternFly, but we don't really give much guidance around this. I'm ok with disabling, but we really should give some guidance on what is correct - otherwise you end up in a infinite loop of "enter number - nope! still not enabled". :)

[mtho11]

@abonas @catrobson yup, working the backend json ack messaging issues right now, I will come address the issues you have identified tomorrow.

[pilhuhn]

On 19 Jul 2016, at 19:46, catrobson wrote:

Yes, we don't normally disable the submit button in PatternFly, but we

If it is not do be disabled, how would you enforce that the user
correctly enters all necessary data?

[mtho11]

Argh! So, I have made all of the changes but I should have recorded a video _Before_ I rebased. Now, I have resolved the git conflicts but things are not looking good. I'm out of time for tonight. Tomorrow, the universe will be in harmony again.

[mtho11]

@abonas, @catrobson
Here are the latest validations and changes:

[catrobson]

@mtho11 looks great. Thanks!