[
https://issues.apache.org/jira/browse/AMBARI-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaimin D Jetly updated AMBARI-2547:
-----------------------------------
Description:
h5. This ticket addresses following issues:
* Refreshing at the moment when none of the stage is running brings up blank
screen. The time window for this is small. Once entered in this state, user
needs to quit the wizard and go through the wizard again to enable security.
* On Google chrome multiple refreshes occasionally cancels the request
(snapshot_1.png). This calls ajax error callback function which sets the error
flag and resets the request Id to its default value. Setting the error flag
will mark the stage as failure and show retry button which can be accepted. But
setting the request Id to its default value makes retry button fire a API for
new request. We should persist the request Id to let the user poll on the same
Id on hitting retry button. Ajax call error while polling request shouldn't
reset requestId. Only task failures in the polled response data should reset
request Id.
* Refresh on the step2 (Configure Services) navigates to step1 of the wizard.
* We keep persisting entire localDb on the server side with the help of an
observable function. This is for multiple browser support. This is large amount
of data and its noticed to have slower ui on refreshes as refresh calls the
function multiple time. We need to isolate other data and persist only security
wizard specific data on the server.
was:
h5. This ticket addresses following issues:
* Refreshing at the moment when none of the stage is running brings up blank
screen. The time window for this is small. Once entered in this state, user
needs to quit the wizard and go through the wizard again to enable security.
* On Google chrome multiple refreshes occasionally cancels the request
(snapshot_1.png). This calls ajax error callback function which sets the error
flag and resets the request Id to its default value. Setting the error flag
will mark the stage as failure and show retry button which can be accepted. But
setting the request Id to its default value makes retry button fire a API for
new request. We should persist the request Id to let the user poll on the same
Id on hitting retry button. Ajax call error while polling request shouldn't
reset requestId. Only task failures in the polled response data should reset
request Id.
* We keep persisting entire localDb on the server side with the help of an
observable function. This is for multiple browser support. This is large amount
of data and its noticed to have slower ui on refreshes as refresh calls the
function multiple time. We need to isolate other data and persist only security
wizard specific data on the server.
> Security wizard: Successive refreshes at some point results in blank screen.
> ----------------------------------------------------------------------------
>
> Key: AMBARI-2547
> URL: https://issues.apache.org/jira/browse/AMBARI-2547
> Project: Ambari
> Issue Type: Bug
> Components: client
> Affects Versions: 1.2.5
> Reporter: Jaimin D Jetly
> Assignee: Jaimin D Jetly
> Labels: security
> Fix For: 1.2.5
>
> Attachments: AMBARI-2547_2.patch, AMBARI-2547.patch, snapshot_1.png
>
>
> h5. This ticket addresses following issues:
> * Refreshing at the moment when none of the stage is running brings up blank
> screen. The time window for this is small. Once entered in this state, user
> needs to quit the wizard and go through the wizard again to enable security.
> * On Google chrome multiple refreshes occasionally cancels the request
> (snapshot_1.png). This calls ajax error callback function which sets the
> error flag and resets the request Id to its default value. Setting the error
> flag will mark the stage as failure and show retry button which can be
> accepted. But setting the request Id to its default value makes retry button
> fire a API for new request. We should persist the request Id to let the user
> poll on the same Id on hitting retry button. Ajax call error while polling
> request shouldn't reset requestId. Only task failures in the polled response
> data should reset request Id.
> * Refresh on the step2 (Configure Services) navigates to step1 of the wizard.
> * We keep persisting entire localDb on the server side with the help of an
> observable function. This is for multiple browser support. This is large
> amount of data and its noticed to have slower ui on refreshes as refresh
> calls the function multiple time. We need to isolate other data and persist
> only security wizard specific data on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
