It looks like it was expected that the price and amount columns would be formatted, but this is not currently the case. So I cleaned this up to be less ambiguous.
If any of these columns were to be configured for formatting, this line could be added back to test for unformatted output.
We now have a new source of truth. You shouldn't use a feature toggle
without adding it to OpenFoodNetwork::FeatureToggle first. All toggles
are added at boot time already.
The products in an order may require several shipping categories like
refrigeration or express. We now filter the categories according to
their support of shipping categories.
This makes a clear distinction between the unfiltered and filtered list.
There may also be some gotchas when modifying the array of an
ActiveRecord relation. It also allows us to write shorter code without
storing a separate variable.
The "subject" is usually the code under test. In this spec it would be
the TagRuleApplicator and not the parameter given to it. So I renamed it
to avoid confusion here.
I discovered that twitter doesn't have 'www' in the url anymore, no '@' symbol and interestingly no trailing slash. I added back the '@' just so we can test that still.
Using a regex group we can cater for optional www in a single regex.
When using a "pick up" shipping method, with a user who doesn't have a shipping address it was impossible to proceed to the payment step because shipping address was invalid.
To fix this, we ensure that "ship_address_same_as_billing" parameter is set to true when using a "pick up" shipping method.
use distributor address when shipping method doesn't require a ship address ; in doing this we follow the same logic as the legacy checkout
Allowing creation and deleting via the user association.
It probably won't be much effort to allow editing and multiple records, but I cut it down to the minimum needed to avoid any further delays.
I couldn't find a way to test a failure in the destroy method, but decided to keep the condition because I thought it was worth having.
Using the clever concurrency testing borrowed from SubscriptionPlacementJob, but I thought a shorter pause time (just 100ms) would be sufficient.
I considered doing this with a new 'state' field (upcoming/open/close), but decided to keep it simple.
Although we won't be allowing multiple in the this PR, we certainly plan to in the future.
The migration helper add_reference couldn't handle the custom column name, so I had to put it together manually.
This will store the URL for each user that wants a notification.
We probably don't need URL validation (it's not done on Enterprise for example). It could be validated by browser input, and anyway will be validated if the webhook actually works or not.
Inspired by Keygen: https://keygen.sh/blog/how-to-build-a-webhook-system-in-rails-using-sidekiq/
Best reviewed with whitespace hidden.
Unfortunately the spec isn't allowed in CI. But it worked on my environment, I promise.
I chose `xit` so that it doesn't run unnecessarily. Perhaps we could use `pending` instead, which would execute, and notify us if it suddenly started working one day. But I doubt it.
This job is responsible for delivering a payload for one webhook event only. It allows the action to run asynchronously (and not slow down the calling process).
The route to update a return authorization must include the order number
as id:
/admin/orders/:order_id/return_authorizations/:id(.:format)
The spec only worked because the controller's ivars were not reset
between requests and the order was already set. But Rails 7 will reset
the ivars and it failed finding the order without a given id.
