We still have the scale stored in two places but in our current system
that's part of a unit's "id".
If the DFC adds that value to its standard then we can use it for lookup
and don't need to repeat it.
* https://github.com/datafoodconsortium/taxonomies/issues/7
I observed new data from the DFC Prototype. It now uses the DFC 1.8
ontology with the hasQuantity object.
It now also uses PUT requests for updates because PATCH is not as well
supported. Rails doesn't care though.
I couldn't observe a request for the CatalogItem yet because the
Prototype failed to send it.
This means you can click on the label name to select the field, and accessibility software can read the label name. I was motivated to do this so that we could update the spec to use label text rather than IDs. But it seems we can't do that with tom-select.
I've updated the styles for all form labels (in admin_style_v3 toggle) to match the design.
An inner join with the billing address was hiding some orders when
sorting by billing address name. Telling Rails that those fields are
referenced triggers an outer left join including orders without billing
address.
But when the Bulk Order Management page sorts by `bill_address_lastname`
then Ransack does most of the magic, except that we need to override the
select in combination with distinct results.
'let!' is executed in the same way as 'before', so it matters which order they are defined in.
For contexts with a single example, I just put it straight into the example.
bill_address is already joined in this query.
The class variable isn't needed outside this scope.
Arguably I think the condition on the select isn't needed; it wouldn't hurt to always select spree_addresses. But I'll try to avoid changing too much..
System specs are expensive. And this spec just looked for the visibility
of certain elements while other tests actually use them and therefore
verify their function much more thoroughly.
People want to test vouchers mainly on a per-enterprise basis.
Replicating this in the system spec makes sure that we are testing the
conditionals in views.
I think that it's a valid case to check a feature toggle against the
user and an enterprise. You may want to check with only one user first,
then activate it for a whole enterprise and lastly activate the feature
globally.
I also kept the per-user check to be backwards-compatible. Some
instances have that enabled already. And for early testing, you may want
to test with only one user first before all customer see it.
The generic FeatureToggleConstraint in routing knows about the current
user but not about the enterprise to edit. We could create a new custom
constraint for routing but it's much easier to handle permissions in the
controller. Let's keep routes simple.
