I removed the caching of `managed_enterprises` in Permissions because
it's just a scope and calling it again is very cheap. And that makes the
method a lot easier to read now that we have a conditional here.
Accessing the managed enterprises via the user instead of a separate
scope on the Enterprise model also reduce the SQL queries. We may want
to use this method in more places. I prefer to keep the
admin-conditional in a permissions class instead of in the model.
Only listing example JSON for now.
This is not part of the official DFC API but it's a DFC-related API and
therefore we put it in the same namespace.
The DFC Permission Module will make authenticated requests to grant
certain platforms certain permissions.
Early versions of the DFC standard demanded that all data is published
in relationship to the authenticated user. But that is not necessary
anymore and can add complications when a platform is authenticated as
client user.
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.
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
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.
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.
