An error was apparent in specs when trying to assign a string as the price. It's not a problem when submitting the form in the browser, I don't know why.
But in any case, it shouldn't be trying to modify a variable passed as a parameter.
Now we don't have to specify the field names on products, yay!
I tried desparately to get it working for the nested variant forms too, but sadly the form builder refuses to acknowledge the relationship. The form builder simply doesn't support a collection of objects in this way.
We could try creating a fake model similar to ProductSet that accepts_nested_attributes_for :products. But it woudl be better to create a custom form builder to do it.
Or, just manually specify field names for now!
I have to admit I don't fully understand why, but it seems to work, even though the rails guide says "only one level of arrayness is allowed (https://guides.rubyonrails.org/form_helpers.html#combining-them). Maybe it's ok here because it's not an array of arrays.
(I think this format is what the reflex spec was already testing).
The DFC doesn't actually specify which cup it means. I don't expect
anyone providing "cup" as unit to measure their produce and expect it to
calculate as a regular volume. It can just be seen as items.
This spec was nested within another block that executed a form submit
which we don't actually need here. So I flattened the structure and
repeated the few missing lines of code. This speeds up the execution.
The fee type is important in the setup because it determines the order
of the fees on the page and we access the rows by their row index.
This commit is best viewed without whitespace changes.
The problem here was that the second fee was created in a `let!` block
that came after a `before` block which visited the page. In some cases
it worked but sometimes the fee wasn't created yet when the page was
loaded. Form changes in the second row were not affecting the second fee
as intended.
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.
