Pagy will pick up the :per_page param by default now, so we don't need to specify `items: params[:per_page]` unless we want to use something beyond that param's value.
This keeps the `OrderBalance` abstraction but removes the old code now
that the feature is enabled for all users in all instances and there are
no bugs reported. It's become dead code.
This (should) considerably improve traces like
https://app.datadoghq.com/apm/trace/917632173599137280?spanID=3163385094622710144&env=production&sort=time&colorBy=service&spanViewType=metadata&graphType=flamegraph&shouldShowLegend=true
by fixing the following 3 N+1s
```
user: root
GET /admin/customers.json?enterprise_id=4
USE eager loading detected
Customer => [:enterprise]
Add to your query: .includes([:enterprise])
Call stack
/usr/src/app/app/serializers/api/admin/customer_with_calculated_balance_serializer.rb:24:in `balance_value'
/usr/src/app/app/serializers/api/admin/customer_with_calculated_balance_serializer.rb:9:in `balance'
/usr/src/app/app/controllers/admin/customers_controller.rb:20:in `block (2 levels) in index'
/usr/src/app/app/controllers/admin/customers_controller.rb:17:in `index'
user: root
GET /admin/customers.json?enterprise_id=4
USE eager loading detected
Spree::Address => [:state]
Add to your query: .includes([:state])
Call stack
/usr/src/app/app/serializers/api/address_serializer.rb:14:in `state_name'
/usr/src/app/app/controllers/admin/customers_controller.rb:20:in `block (2 levels) in index'
/usr/src/app/app/controllers/admin/customers_controller.rb:17:in `index'
user: root
GET /admin/customers.json?enterprise_id=4
USE eager loading detected
Spree::Address => [:country]
Add to your query: .includes([:country])
Call stack
/usr/src/app/app/serializers/api/address_serializer.rb:10:in `country_name'
/usr/src/app/app/controllers/admin/customers_controller.rb:20:in `block (2 levels) in index'
/usr/src/app/app/controllers/admin/customers_controller.rb:17:in `index'
```
This popped up after improving the balances calculation. Now, that it's
fast, it's clear that are more performance problems on that endpoint.
We'll see if there are any left after this.
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.
Closes#6727.
This avoids the authorization of all the VOs of the hub, which will go
through VOs that may have become invalid due to their underlying product
not belonging to the supplier the hub has permissions with (or any other
data integrity issue).
This is utterly confusing for the user who is only given a generic error
and doesn't understand what's wrong with the particular VO they changed,
while it may be fine after all. What's more, this often results in
a customer support request, which then may end up with a dev finding out
which VO is broken.
Also, there's no point in loading them from DB if the users didn't touch
them.
