- 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>
The webhook_payload now includes :number in the order slice, but
webhook_service_spec still expected the order hash without it. Since
hash_including only matches at the top level, the nested order hash
comparison was strict and failed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The spec was not really testing the order of users appearing on the
page. It's also a UX detail only visible to super admins which is not
important to test. So I'm not investing time to fix it.
The locale config is set in application.rb from environment variables
already. We don't need to repeat that logic in test.rb. And because it
was outdated, the language switcher was actually broken in the test
environment. We did have an English selector for the fallback `en` even
though we were already displaying English as en_TST. And after
switchting to Spanish, we could switch back because en_TST was not in
the available locales.
I now fixed the test with the right assumption and the config to solve
the problem.
I considered a few ways to do this. Cloned products are done with MutationObserver but it doesn't quite sit right with me. A dedicated controller for newly added rows would provide a good general solution. But do we want yet another controller? I'm not sure. This works and is pretty simple (although it requires a quick loop over _every_ form element.. let's see if we can avoid that.)
Taler puts the payment completion into the hands of the user. So we
can't strictly finalise the payment and order together.
And in the bigger picture, it should be okay if a payment goes through
but we have to abort checkout due to stock issues. Then we want to be
able to check out again, using the existing complete payment. Any
refunds can be handled later by the shop owner.
