Add option to go back in history on successful Resource update/create #4186
Unanswered
wdelfuego
asked this question in
Ideas & Feature Requests
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The issue
When users cancel the editing of a Resource by clicking cancel, they are sent back to where they came from. That is useful when the Edit view was directly opened from a custom Dashboard card or from a related resource's 'hasMany' listing; the user can pick up right where they left off after they decide not to edit the item.
When the user saves their edits, however, they are always sent to the Resource's
redirectAfterUpdate
location. This breaks the user's flow and forces them to manually navigate back to the place from where they initially opened the Edit view.The same issue applies to opening an Edit view for resource B from the 'hasMany' listing on the detail view of resource A. Cancelling the edit leads back to the detail of A while saving it leads to the detail of B. This is an inconsistency in how Nova behaves that I think would be nice if we could customize it. (as default behavior the way it currently works is fine).
The solution
The feature that'd be nice to have would be to add something like
App\Nova\Resource::redirectBackAfterUpdate()
in the backend and to update thehandleResourceUpdated
in the frontend to returnwindow.history.back()
in that case, instead ofNova.visit(redirect)
. The same customization option should probably apply to resource Creation.My use case
I have a custom card on my Dashboard that indicates Resources that need attention. It gives the user an 'Edit' button directly to the Resources' edit view. I want users to come back to this Dashboard whether they cancel or save the Resource edit, so they can directly see what changed as a consequence of their edits:
I could hardcode that dashboard in the
redirectAfterUpdate
location, but that only solves this specific instance and wouldn't allow me to link to the same resource from a different location, nor does it solve the issue when editing objects from a HasMany relationship. It would also cause problems for users who have permissions to edit those resources, but not to see that specific Dashboard.Beta Was this translation helpful? Give feedback.
All reactions