So I think the issue is that all the HTML is wrapped on an
`off-canvas-wrap` class that is used for doing the sidebar car open over
main content. The problem is that when this car sidebar is open body of
HTML overflow is changed to `overflow: hidden` and search bar use CSS
`position: sticky;` which doesn't work when its parent has overflow
hidden. The issue was that `off-canvas-wrap` had an `overflow: inherit`
which means when body is set to overflow hidden this div inherits it and
break search bar position sticky when cart sidebar is opened. The
solution is to use `position: initial` which means use what a div has as
default value for `overflow` which I think it's `visible`. This class is
overriding the same class that comes from Foundation Framework that set
this div to be `overflow: hidden`. The override was added when [we added
search sticky](ff69389bb0)
More info about the problem with [position:sticky and its parent having
overflow hidden](https://css-tricks.com/dealing-with-overflow-and-position-sticky/) also info about [position initial vs inherit](https://stackoverflow.com/a/29661356)
Running script/prepare_imported_db.rb failed because
Spree::PaymentMethodDistributors couldn't be found. This problem is
described in the Rubocop docs:
https://rubystyle.guide/#namespace-definition
accessed before being loaded
Show we check for $.ready when jQuery is not downloaded yet in the
browser. The solution is to check if document is ready with plain DOM
javascript event `DOMContentLoaded`
So the thing is we initialize jQuery plugin on `admin/util.js.erb` but
then we override those defaults on order_cycles.js.erb.coffe. Now both
plugin initializations use the same defaults. Also added 3 missing
translations for `Done`, `Now` and `Time` copies on that timepicker popover
See: https://community.openfoodnetwork.org/t/hubs-managers-can-choose-the-adapted-weight-and-measure-units-for-their-shops-given-their-own-local-situation/1289/11
We're not entirely sure what needs to be changed in order for this to
accurately work with shipping and other parts of the eCommerce platform.
We are assuming that so long as we canonically store the weight scale
in grams, that the shipping calculation will be able to do what it needs
to. So if we put in values for "oz" as grams, we may not need to do
much else in order to let product(s) be sold by the pound (or ounce).
Next steps appear to be:
- [ ] When looking at an order as a customer, do we want to show pounds
instead of grams? (See: http://localhost:3000/orders/R125684626)
- [ ] Compile a list of tests that are worth writing (because we have
no confidence that we know what we are supposed to be doing in
order for this feature to be "ready" to be used by people.)
- [ ] Write a test that demonstrates when we create a product with a
variant in pound that the product's shipping weight is correctly
calculated?
- [ ] Do we want to think about i18n?
