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
When calling `save!` without changing any attributes then Rails doesn't
always touch other records because nothing changed. So I changed the
spec to `touch` explicitely and it turns out that everything passes.
Tada, our code seems correct and it was only the spec which seemed
broken in Rails 7.
I didn't observe it but if the spec code would run within the same
millisecond then we wouldn't be able to observe a change to
`updated_at`. Time travel solves this potential problem.
I found this because Rails 7 converts timestamps to database precision
straight away. While we may have some broken logic in the code, most of
these cases may just be broken spec code. Watch this space.
Storing a timestamp to the database has less accuracy than a Ruby Time
object. So `updated_at` changes after being written and loaded from the
database. Rails 7 accounts for that by rounding it in the model already
before it's written to the database. That made one spec fail.
Before it said:
```
WARNING: Using the `raise_error` matcher without providing a specific error or message risks false positives, since `raise_error` will match when Ruby raises a `NoMethodError`, `NameError` or `ArgumentError`, potentially allowing the expectation to pass without even executing the method you are intending to call. Actual error raised was #<RuntimeError: Cannot use t(".legacy_translation") shortcut because path is not available>. Instead consider providing a specific error class or message. This message can be suppressed by setting: `RSpec::Expectations.configuration.on_potential_false_positives = :nothing`.
```
Instead of knowing the input id generated by select2, we now rely on the
fact that the owner is in the fifth column. Both could change but this
is less code.
I observed this data but I'm unsure about the root cause. It could be
that the SQL query fetching this data needs tweaking to return the fee
name in this case or it could be that it's not available (deleted).
In any case, I thought I document what's happening and make this
summarizer more robust before looking into the query.
