However, for such a logged user, a request to /v1/config/types returns an empty response. This is because the types are attached to the root organization and aren't defined to be accessible by the sub-organizations (sub_organizations = false).
We can't simply set sub_organization to true on the organization and user types, or the parent items themselves would be accessible by the user (and we don't want to give him access to the root organization).
Edit: items have a sub_organization attribute as well, but for an unknown reason (bug?), even when I set a value of false, it appears to be set to true in the database.
Edit 2: I got it, it's a sneaky bug in Model\Item: property_exists($model, 'sub_organization') always returns false (even if it has been set). This is probably because models attributes are not normal properties of the object. It wouldn't work as expected anyway since $model->sub_organization is always accessible.
How to reproduce?
What was expected?
The organizations and users are correctly loaded (accordingly to the user's permissions).
What's the issue?
In the frontend, the items are loaded by
listItems(typeInternalname)
. The equivalence between the type internalname and its id is found by asking the types configuration to the backend.However, for such a logged user, a request to
/v1/config/types
returns an empty response. This is because the types are attached to the root organization and aren't defined to be accessible by the sub-organizations (sub_organizations = false
).We can't simply setsub_organization
totrue
on theorganization
anduser
types, or the parent items themselves would be accessible by the user (and we don't want to give him access to the root organization).Edit: items have a
sub_organization
attribute as well, but for an unknown reason (bug?), even when I set a value offalse
, it appears to be set totrue
in the database.Edit 2: I got it, it's a sneaky bug in
Model\Item
:property_exists($model, 'sub_organization')
always returnsfalse
(even if it has been set). This is probably because models attributes are not normal properties of the object. It wouldn't work as expected anyway since$model->sub_organization
is always accessible.