And also STRIPE_ENDPOINT_SECRET just in case it's ever used in tests.
Re-records Stripe tests. But some failed... :'(
Failed examples:
rspec ./spec/lib/stripe/credit_card_cloner_spec.rb:71 # Stripe::CreditCardCloner#find_or_clone when called with a valid customer and payment_method clones both the payment method and the customer
rspec ./spec/lib/stripe/payment_intent_validator_spec.rb[1:1:1:1:17:1:2] # Stripe::PaymentIntentValidator#call when payment intent is valid valid non-3D credit cards are correctly handled behaves like payments intents from UnionPay (debit) captures the payment
We should not need additional hard coded keys other than the API key and the CLIENT_ID; this PR removes hard coded customer ID - creates one instead
Undoes Stripe.api_key deletion
This was a mixup with an ongoing PR in which we remove the need to call api_key in each individual spec.
Fix the payment stubbing, payment `process_offline!` was stubbed to
return true and payment `completed?` was also stubbed to return true.
`process_offline!` did not change the payment status in the database,
meaning that any call to 'order.pending_payments' after that would
return the payment which should have been processed offline, and
therefore completed. This created some unwanted side effect, resulting
in the test breaking.
Using a new 'fit' modal size.
On smaller screens, we need to allow the image to shrink. That's a good general rule, but I was hesitant to make it a global rule..
- put former remote toggle ctrller toggle method
in new toggleAdvancedSettings in more generic toggle ctrller
- modified acordingly the 2 associated views
- put former test code in more generic ctrller test file
- deleted now useless ctrller + test files
Using browser validation. I didn't use model validation because the on_hand pseudo-attribute doesn't support it.
But.. it turned out to not be so simple. Browser validation can't work if the field is hidden, and breaks the javascript. So now I made the javascript smarter, and the end result is more helpful I think.
Doing so, enables a homepage for that enterprise, which surfaces issue #12076. The test as been set as pending, which needs to be changed when the issue is fixed
The second example on this sepec is commented out, and will be addressed on the following commit
Sets user email
We need to set an email for the user we're creating; if we don't, then each time we run the spec, a new user will be created with a random email - as per user factory. This will translate in a (slightly) different HTTP request each time the spec is ran, and will cause a VCR recording error as new cassettes cannot be recorded in under the CI.
Re-recordes cassette after rebase
