Without syncing the two threads with a lock, the spec could accidentally
pass even if the code is broken. It was accidentally removed during
refactoring in b0fa1464f.
Where the presence of an object is being validated and that object comes from an *association*, we should use `validates :object, presence: true` instead of `validates :object_id, presence: true`.
This does not apply in the same way to validations on uniqueness of certain attributes, such as `validates :object_id, uniqueness...`
This will let us branch by abstraction. All existing calls to
`#outstanding_balance` will go through `OrderBalance` hence, will
check the feature toggle.
Note that by default, `OrderBalance` will end up calling
`#old_outstanding_balance`. As the name states, that's exactly what
`#outstanding_balance` was so far. This means no consumers will see any
change in behavior. We just added on item in the call stack (sort of).
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.
The `Spree::Admin::OrdersController`'s test file quite long (as well as
the controller itself) but it'll grow more in the upcoming commits.
That's just a symptom of that controller having too many
responsibilities. It does much more than CRUD on `Spree::Order` (the
Rails convention).
Things like invoices are an entity on their own and would better fit
into a `InvoicesController`. Hopefully, splitting up the tests is hint
for the next dev to do that.
