Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
| Dev |
|
| QA |
|
| Priority | Low |
| Complexity | Unknown |
| Component | App - Version Control - GIT |
| Version | 14.0 |
When there is an ongoing operation, like when doing a Pull, or a Push, or Fetch operation, the Message dialog displays the "Processing..." status and provides a Cancel button. Clicking on the Cancel button opens up a confirmation dialog if the user is sure that he really wants to cancel or not. However, during this time, the operation might finish in the background, and then clicking the Yes button has no effect (seems like clicking the No button).
In this situation, when the Yes/No confirmation dialog shows up, the background operation should pause; or, if letting it continue, when clicking the Yes button, either any changes that were made should be canceled/reversed/undone, or, maybe the easiest to implement, to display a message telling the user that canceling is not possible anymore as the operation already finished.
|
152 KB
The cancel button (which invokes jgit api's cancel operation) is not similar to rolling back a transaction. The cancel operation basically aborts the operation at the time the cancel is initiated. It does not perform any sort of rollback. In your testing, please verify this by doing a pull and then canceling the pull before it is finished. This is fairly standard behavior for version control, including svn.
I don't think we have to change the current behavior. Our svn GUI uses the same approach and we have not received any complaints from users.
After you confirm the behavior of cancel, please go ahead & close out this issue.
Yes, I can confirm the behavior.
If pausing or rolling-back is not the way of doing it here, then I would still suggest the last case, to display a message telling the user that canceling is not possible anymore as the operation already finished.
Please see attached video (ads_git_cancel_yes.webm), I found it counter-intuitive pressing the Yes (cancel the operation) button, and then seeing an operation-successfully-finished message. After the Yes button was pressed, if the operation finished in the background, an info dialog should be shown -- for example: "Canceling was not possible as the operation already finished." with an "OK" button. This would be more user-friendly, and would eliminate the no-distinction between the Yes and No buttons at that given moment.
However, if the current way ADS works is considered acceptable, the issue can be Closed.
Yes, I can confirm the behavior.
If pausing or rolling-back is not the way of doing it here, then I would still suggest the last case, to display a message telling the user that canceling is not possible anymore as the operation already finished.
Please see attached video (ads_git_cancel_yes.webm), I found it counter-intuitive pressing the Yes (cancel the operation) button, and then seeing an operation-successfully-finished message. After the Yes button was pressed, if the operation finished in the background, an info dialog should be shown -- for example: "Canceling was not possible as the operation already finished." with an "OK" button. This would be more user-friendly, and would eliminate the no-distinction between the Yes and No buttons at that given moment.
However, if the current way ADS works is considered acceptable, the issue can be Closed.
Kin-Hong, pls read Cristian's latest comment and see the video that he posted. When the user clicks "Yes", does jgit let us know that the operation has already completed and there is nothing to cancel? If so, we can do as Cristian has suggested. Otherwise, we can keep the behavior as is and close the issue.
Kin-Hong, pls read Cristian's latest comment and see the video that he posted. When the user clicks "Yes", does jgit let us know that the operation has already completed and there is nothing to cancel? If so, we can do as Cristian has suggested. Otherwise, we can keep the behavior as is and close the issue.
I think instead of changing the content of the cancel dialog, we could just dismiss it when the operation finishes. Will that work?
I think instead of changing the content of the cancel dialog, we could just dismiss it when the operation finishes. Will that work?
When the operation finishes and the Cancel confirm dialog is still displayed, the dialog will be dismissed.
When the operation finishes and the Cancel confirm dialog is still displayed, the dialog will be dismissed.
Verified using ADStudio 14 Dev 40, the cancel dialog is now dismissed if the background operation finished before pressing Yes or No.
Closed.
Verified using ADStudio 14 Dev 40, the cancel dialog is now dismissed if the background operation finished before pressing Yes or No.
Closed.
Issue #8552 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |
The cancel button (which invokes jgit api's cancel operation) is not similar to rolling back a transaction. The cancel operation basically aborts the operation at the time the cancel is initiated. It does not perform any sort of rollback. In your testing, please verify this by doing a pull and then canceling the pull before it is finished. This is fairly standard behavior for version control, including svn.
I don't think we have to change the current behavior. Our svn GUI uses the same approach and we have not received any complaints from users.
After you confirm the behavior of cancel, please go ahead & close out this issue.