After deleting an order at /admin/commerce/orders/carts, you get redirected to /admin/commerce/orders.
I think it would be better to stay at /admin/commerce/orders/carts, so you could delete another shopping cart order.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | commerce-operations_links_destination-1483056-16.patch | 956 bytes | maciej.zgadzaj |
| #14 | 1483056-operations-field-redirect-14.patch | 14.82 KB | mr.baileys |
| #13 | 1483056-operations-field-redirect-13.patch | 14.49 KB | mr.baileys |
| #10 | 1483056-operations-field-redirect-9.patch | 14.77 KB | mr.baileys |
| #5 | 1483056-operations-field-redirect-5.patch | 13.06 KB | mr.baileys |
Comments
Comment #1
rszrama commentedAgreed. This has annoyed me, too. I wonder if we can do it simply through Views by adding a destination parameter to the delete link. I'm not sure if that's possible, but it's the first thing to investigate.
Comment #2
mr.baileysAdding a destination to the query string will indeed resolve this issue, similar to how this issue was solved for products in #1128734: Redirect Product operations links back to the main View.
Since adding this code to the order operations field handler would duplicate the code from the product operations field handler, and since a lot of the "operations field" code is shared between customer/product/order/..., I moved the shared code into a new base class, commerce_handler_field_operation.
Child classes of commerce_handler_field_operation implement the get_operation_links function to return the operations they want to show.
Comment #3
mr.baileysupload failed for some reason, re-attaching the patch.
Comment #5
mr.baileysadmin/commerce/[orders|products|customer-profile]ifdestinationis given and not external.Comment #7
mr.baileys#5: 1483056-operations-field-redirect-5.patch queued for re-testing.
Comment #8
mr.baileysRequesting a re-test since none of these failures occur during local testing.
Comment #10
mr.baileysOk, my bad, forgot to include one file in the previous patches causing the failures...
Comment #11
rszrama commentedOut of curiosity, how would this patch affect people who have already customized the various Views that include operations links? Would the existing links still work as they did before, or is there something special in the update that would require them to be updated manually for already altered Views?
Comment #12
mr.baileysThe only way this will affect custom views is that the operations field for Orders, Payments and Products will get an additional option ("Add destination query parameters …"), which is not set by default.
So these customized views would not automatically be changed by this patch, which I assumed is preferred?
Comment #13
mr.baileysActually, I needed to double-check that the option actually exists to prevent undefined errors. For some reason these errors didn't occur when I first tested this scenario.
Comment #14
mr.baileysforgot a file...
Comment #15
jonathan_hunt commentedWorking for me, thanks.
One gotcha is that when ticked in the context of one view (admin/commerce/orders/carts) there's also a destination parameter added to operations in other views (admin/commerce/products, admin/commerce/file-licenses).
[Edit: On checking a second site, I see destination is already present on products and licenses views.]
Comment #16
maciej.zgadzaj commentedUm, considering that "Add a destination parameter ..." options is already there for "Commerce Order: Operations links", this simple patch should be enough now.
Comment #17
rszrama commentedHeh, yeah, somewhere along the way I added the destination option to the order operations handler (likely from a separate issue) without updating this issue. Still, mr.baileys's patch goes further in that it abstracts our operations link handlers a bit and updates the "Cancel" link on delete forms to use an existing destination parameter if available so they go back to the right place. It likely needs a re-roll now, though.