[RFR] Delete view: back to previous state, not edit or list view #538
Conversation
| @@ -3,7 +3,7 @@ | |||
| define(function () { | |||
| 'use strict'; | |||
|
|
|||
| var DeleteController = function ($scope, $state, WriteQueries, notification, params, view, entry) { | |||
| var DeleteController = function ($scope, $window, $state, WriteQueries, notification, params, view, entry) { | |||
There was a problem hiding this comment.
$state isn't used anymore. Please remove it entirely from the controller.
|
I remember thinking about it, too, but I think this creates problems in e2e tests. As protractor failed to run, I relaunched the build, let's see. |
|
Local version of Protractor reported no failures now. |
| @@ -43,23 +40,19 @@ define(function () { | |||
| }; | |||
|
|
|||
| DeleteController.prototype.back = function () { | |||
| var $state = this.$state; | |||
| var $window = this.$window; | |||
There was a problem hiding this comment.
No need of a temp variable here. Just do a this.$window.history.back().
|
This PR needs rebase. :) |
jpetitcolas
changed the title
|
Bump, can you rebase and refactor the |
vasiakorobkin
force-pushed
the
delete_back_to_prev
branch
from
8a7280f to
9c62baa
Compare
|
Rebased branch and One test (filter button should reappear once an unpinned filter is removed) is failing if browser window, opened by Selenium is too small. May this be a reason for Travis CI fails? |
vasiakorobkin
force-pushed
the
delete_back_to_prev
branch
from
9c62baa to
c473394
Compare
|
Tests on master are passing. Can you try to rebase to check if it fixes your PR? |
vasiakorobkin
force-pushed
the
delete_back_to_prev
branch
from
c473394 to
f185942
Compare
|
Rebased. All tests has been passed successfully. |
[RFR] Delete view: back to previous state, not edit or list view
| entity: entityName, | ||
| id: this.entityId | ||
| }, $state.params)); | ||
| this.back(); |
There was a problem hiding this comment.
looks to me like this causes a regression: if you click "delete" while on the showView page, the new code sends you "back" to that page which 404's.
If I press
Cancelin delete view I want to go back where I came from, not to the deleted object's edit view (the delete button may be pressed in list view or inreferenced_listfield of other entity, not always in edit view; also list view or edit view or both may be disabled for deleted entity - than we would have an error). Same thing with after-delete-redirect.I think it is much more logical to just redirect user to the previous entry in history, than to specifically edit view or list view. Is there some problems with this approach? I don't see any.