- Set HTTP_REFERER in cancel action specs so they test the redirect to
the actual order page (not the cancel path, which was the implicit
referer in controller specs)
- Keep response.body match pattern (consistent with checkout_controller_spec
for CableReady redirects — redirect_to matcher does not work here since
the cancel action uses cable_car.redirect_to, not a Rails redirect)
- Remove doc/demo screenshots; images to be added to PR description instead
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When a guest places an order and tries to cancel it from the order
confirmation page, the cancellation silently failed and redirected
to the home page. The guest was left unsure whether the order was
cancelled, and the hub received no cancellation notification.
Root cause: two missing pieces for guest (token-based) authorization:
1. The `:cancel` ability in Ability#add_shopping_abilities only checked
`order.user == user`, ignoring the guest token. The `:read` and
`:update` abilities already support `order.token && token == order.token`
as a fallback — `:cancel` now does the same.
2. The `cancel` action called `authorize! :cancel, @order` without
passing `session[:access_token]`, so even with the corrected ability
the token was never evaluated.
Fixes#13817
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Rewrite the loop "break unless a = order.next! while !order.delivery?" to correct the offenses. Not adding a helper because the change was only needed in a couple of places.
Therefor, for the right controllers, simply implements:
```
include WhiteLabel
before_action :hide_ofn_navigation, only: [:show, :edit]
```
This is mort robust, since we're working in a controller level, not parsing URLs...
There are 4 or 5 different places in the app where we reference a :token and params[:token] for completely different purposes (they're not even vaguely the *same* token).
This is an attempt to clarify the places in the app where we use params[:token] in relation to *orders*, for allowing guest users (who are not logged in) to view details of an order they have placed (like after checkout completion), and differentiate it from the various other places where params[:token] can actually be used for something entirely different!
