A while ago I was told that an absent stock limitation means unlimited
stock. But that can't be distinguished from just not wanting to update
the stock level.
In the meantime, a new stock policy model was proposed. But for now we
have a workaround, setting `-1` as value for unlimited stock.
* https://github.com/datafoodconsortium/ontology/discussions/112
There will be lots and lots. The sales data root object is also the
authenticated person. The data has its own URL (semantic id) which
doens't need to contain the user id.
The service object can also be tested more easily. I'm setting up the
test data here.
We want to use this image in the Discover Regenerative portal in
Australia. The property is read-only and the API doesn't support the
upload of a new file.
The enterprise factory needed fixing as well. This trait hadn't been
used anywhere else.
The `dfc-b:hasType` value can only be parsed as object id if the context
contains:
```
"dfc-b:hasType":{
"@type":"@id"
},
```
The standard context includes this and it's easier to use. Now that the
URIs of product types are correctly resolved, we don't need to
substitute the URI manually.
Also dropped an old unneeded spec for backwards compatibility.
We observed an error when an instance requires a tax category and we
tried to create products via the DFC API:
* https://github.com/openfoodfoundation/openfoodnetwork/issues/11212
But I found that the error only appears after changing the instance
config without declaring a tax category as default. The right setup as
in the spec does work. The spec passes.
I don't think that this needs any fix. We shouldn't assign any tax
category just because it's required. The instance manager needs to
select a default.
A DFC SuppliedProduct relates to a Spree::Variant and when updating its
name we only want to change the name for that variant. Otherwise, when
we update the name of the product, it would update the name for all
variants and all the corresponding SuppliedProducts.
The Spree::Variant in OFN corresponds to a DFC SuppliedProduct. But
several Spree::Variant can be grouped under one Spree::Product which
wasn't exposed on the DFC API.
I'm adding a custom property here which can be used internally and
shouldn't break any other DFC tools.
A gotcha of this first test implementation:
The `ofn:` prefix has not been defined in the context. Software needs
to know that this is an Open Food Network attribute or ignore it.
We could define our own context and ontology and publish it on our
website but I don't see any benefit of that at this point.
When the application is not preloaded then running Rspec doesn't know
Rails until the spec helper is loaded. So we can't use Rails to find the
path of the spec helper. This has been fixed before but the DFC Address
code was developed at the same time and missed.
