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.
With the help of the bullet gem, and since we remove a couple of N+1s
already, remove them all was just a few keystrokes away. This commits
gets us from 42 SQL queries to 17, and 364.5ms to 253.9ms on my machine
where I just have the sample data's orders. As usual, this will have
a much bigger impact in scenarios with more data.
This removes the N+1 queries caused by
`Api::Admin::OrderSerialier#ready_to_capture` when used from
`Api::OrdersController#index`. While it's fine for the single-order
controller actions, it's not for this one that deals with a collection
of orders.
Fortunately, `SearchOrders` is used only in this controller action so we
can put the `includes` calls there, otherwise, we would need to refactor
it a bit to pass in a context-specific AR relation.
This makes them more changeable and robust. Ruby will raise
NoMethodError on typos while it'll silently create a new ivar without
us noticing. Also, in my experience, a reader method gives more room to
future refactorings and eases testing because methods are easier to
stub.
The controller already does so, then, we can pass it to the service and
avoid that extra round-trip to the DB and save some memory. Spree::Order
is a rather bulky object (God object code smell perhaps) and it'll
surely make a difference.
