Uploaded images can be several MB in size. While offering the big size
would enable other apps to resize it and store the image size they need,
we have only one app using it in practice and it's using the image
directly. It's much simpler and if a default size will work for others
in the future then why not just serve that.
We can revise this in the future. There is a DFC discussion about
publishing several sizes which I started:
https://github.com/datafoodconsortium/ontology/discussions/77#discussioncomment-8228094
Add our own address to include `region`, currently not supported
by the DFC connector.
`region` is already included in the next branch of data-model-uml:
729eba31a5
To me removed once the DFC connector is updated
Update pending payment for cash order, so we can take into account any
changes affecting order toral (shipments, line item quantity etc...).
This is to allow payment capture to cover the order total, not just
the amount due at checkout.
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.
The given productType.rdf file doesn't give us any context for `dfc-pt`,
so there was no reason to do that.
We still need to do some substitution in the importer, as some times
we are given `dfc-pt` as input data.
It relies on having dfc_name populated on the given taxon.
Matching is as follow:
- parse the DFC product types and store in PRODUCT_TYPES if needed
- match the dfc_name against PRODUCT_TYPES
- call the method returned on the DFC connector
Currently anything but the leaf level is modelled as a
DataFoodConsortium::Connector::SKOSInstance, which isn't supported
by the connector as "hasType" for a product. The lead level is modelled
by DataFoodConsortium::Connector::SKOSConcept which is supported by
connector. On top of is `#narrowers`, `#broaders`and `#prefLabels`
aren't set making it very difficult to travers the Product Type tree.
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.
