Previously we only set these part-way through deployment, so the values could be out of sync between our ENV vars and Spree::Config (which itself is a mix of both cached values and database-persisted values).
The state should have changed in the database if the payment was processed successfully, and the memoized version here will not know that without a reload.
If the page is reloaded after the payment has already gone through, we can skip the processing and give a non-error response; the payment is already completed and Stripe's response confirms it was successful.
When we're fetching the payment intent via PaymentIntentValidator in StripeSCA#purhcase (to capture it), we want it to fail loudly if it's not in "requires_capture" state. We're now also re-using the same PaymentIntentValidator service to check if payment processing was *successful*, in which case we need it *not* to fail loudly if the state == "succeeded", eg != "requires_capture".
This guard clause was returning an instance of an unpermitted Params object (containing a blank hash) here, which was causing unexpected results in various places. Returning a blank hash explicitly resolved the issue.
Fixes:
4) Admin::OrderCyclesController create as a manager of a shop when creation is successful returns success: true and a valid edit path
Failure/Error:
@order_cycle_params ||= PermittedAttributes::OrderCycle.new(params).call.
to_h.with_indifferent_access
ActionController::UnfilteredParameters:
unable to convert unpermitted parameters to hash
# ./app/controllers/admin/order_cycles_controller.rb:245:in `order_cycle_params'
# ./app/controllers/admin/order_cycles_controller.rb:44:in `create'
# ./spec/support/controller_requests_helper.rb:49:in `process_action_with_route'
# ./spec/support/controller_requests_helper.rb:27:in `spree_post'
# ./spec/controllers/admin/order_cycles_controller_spec.rb:124:in `block (5 levels) in <module:Admin>'
This for new changes to the enterprise registration/signup flow where a map will be displayed when people are filling in their address. On this map people can check the geocoder has geocoded their address correctly and if not they can manually adjust their latitude/longitude on the map.
But currently every time someone changes their address in the Admin > Enterprise > Address section the address would automatically be geocoded so this could overwrite the latitude/longitude that was set during sign up. To prevent the latitude/longitude from being overwritten this add's a checkbox which people need to explicity click if they want their address to be automatically geocoded, otherwise it will just use the manually configured latitude/longitude.
Note this new feature which allows people to select their location on a map during registration only works with Google maps so far. So if an instance is using Open Street Map this change also adds support for passing a :use_geocoder parameter to the Api::EnterprisesController during registration so that the address will be geocoded on the backend without the use of a map.
This for new changes to the enterprise registration/signup flow where a map will be displayed when people are filling in their address. On this map people can check the geocoder has geocoded their address correctly and if not they can manually adjust their latitude/longitude on the map.
But currently every time someone changes their address in the Admin > Enterprise > Address section the address would automatically be geocoded so this could overwrite the latitude/longitude that was set during sign up. To prevent the latitude/longitude from being overwritten this add's a checkbox which people need to explicity click if they want their address to be automatically geocoded, otherwise it will just use the manually configured latitude/longitude.
Note this new feature which allows people to select their location on a map during registration only works with Google maps so far. So if an instance is using Open Street Map this change also adds support for passing a :use_geocoder parameter to the Api::EnterprisesController during registration so that the address will be geocoded on the backend without the use of a map.
