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.
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.