[
https://issues.apache.org/jira/browse/AMBARI-14574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106185#comment-15106185
]
Keta Patel commented on AMBARI-14574:
-------------------------------------
[~aantonenko], I tried out a couple of different ways from the suggestions you
mentioned as follows:
Attempt 1 and 2 are taken from AMBARI-12737. The fix in this Jira resolved the
issue of keeping the steps following the current step disabled, so that a user
could navigate to any step before the current step but not to the ones after
the current step. I used the 'isStepDisabled' object used in this fix for the
attempts below.
Attempt 3 uses 'transitionInProgress' property.
Attempt 1 (using AMBARI-12737):
**********
Using "if a step is disabled or not" as the check:
If we use App.router.installerController.isStepDisabled.value for a step, it
will be false if that step is the current step or a step that comes before the
current step. So if this check is used in the controller’s ‘submit’ function
for a step, it will not filter out the duplicate Next button clicks for that
step. This is because a duplicate Next button click will be calling the same
controller ‘submit’ function.
App.router.installerController.isStepDisabled.value for a step stays ‘false’
from this point onwards unless the user jumps back to an earlier step. So this
check fails in the controller.
!attempt_1_controller.png!
This check also fails for steps that call the installer’s ‘next’ function
directly. For example, in case of step1, the installer’s ‘next’ function is
called on Next button click.
App.router.installerController.get(‘isStepDisabled’).findProperty(‘step’,1).get(‘value’)
will always be false if the execution reaches this point in the installer.
Hence, this check won’t be effective to filter out duplicate calls for steps
where installer’s ‘next’ function gets called on the Next button.
!attempt_1_installer.png!
Attempt 2 (using AMBARI-12737):
**********
Using "if the current step is the one meant to call the submit/next functions"
as the check:
if we use App.router.installerController.get('currentStep') to ensure that a
submit button click was meant for the current step, then it works correctly in
cases where the controller is called on Next button click. The following
example checks for the current step in the ‘submit’ function of the controller
for step0. Any duplicate calls for step0 will be filtered out by this check.
!attempt_2_controller.png!
In cases where the Next button directly calls the installer ‘next’ function,
this check doesn’t work because a duplicate call from installer’s ‘next’ will
also call installer’s ‘next’ for the following step. Hence the check fails.
This can be seen in the following example where ‘step1’ calls installer’s
‘next’ directly. A duplicate call on step1’s Next button will also call the
installer’s ‘next’ for the ‘currentStep’ which becomes ‘step2’ after
‘router.transitionTo(‘step2’)’ line.
!attempt_2_installer.png!
Attempt 3 (using 'transitionInProgress'):
**********
Using "transitionInProgress to check if a transition is already in process
before processing a Next button click" as the check:
I tried re-using the ‘transitionInProgress’ variable to check for duplicate
Next button clicks. The trunk uses ‘transitionInProgress’ only in the installer
when the router is transitioning to the next step. This variable is not used in
controllers of the steps. Since the Next button clicks call the controller’s
‘submit’ function for some steps and installer’s ‘next’ function for the other
steps, we will not have uniformity in terms of where to set or reset the
property. If we use this property in the controller’s ‘submit’ function, then
we need to remove this check from the installer’s ‘next’ function for that step
(in case where that step has this check in the installer) in order for the
transition to proceed. But this removal could allow multiple clicks from the
previous steps to propagate through this step. Hence, we can’t remove the
‘transitionInProgress’ checks from the installer’s ‘next’.
!attempt_3_adding_check_for_step1.png!
!attempt_3_removing_check_from_step3.png!
Please correct my understanding and approach to fix this issue.
> multiple clicks on "Next" button causes skipping of steps while installing a
> cluster
> ------------------------------------------------------------------------------------
>
> Key: AMBARI-14574
> URL: https://issues.apache.org/jira/browse/AMBARI-14574
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
> Affects Versions: 2.1.1
> Reporter: Keta Patel
> Assignee: Keta Patel
> Attachments: AMBARI-14574.patch, attempt_1_controller.png,
> attempt_1_installer.png, attempt_2_controller.png, attempt_2_installer.png,
> attempt_3_adding_check_for_step1.png, attempt_3_removing_check_from_step3.png
>
>
> On installation wizard, multiple clicks on the "Next" button can cause
> skipping of steps. The timing of the 2nd click decides if that click will be
> processed again or not. The following JIRAs had the same issue:
> AMBARI-7195
> AMBARI-7315
> The fix for the above issues helps to resolve most part of the problem. But
> if the user happened to click again at the point when the last callback
> function has just completed (and thus, has made the "Next" button clickable
> again) but the next step has not yet completed its rendering, then the 2nd
> click gets processed again. The "current step" was already updated in the
> code to point to the next step, from the 1st click. So when this 2nd click
> calls the "next" function in the router, the subsequent step of the "current
> step" gets set as the current step. As a result we skip steps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
