Affects Version/s: 7.0.0
Fix Version/s: 7.0.0
When calling a CREST operation from within a script that was triggered by a different CREST operation on a different managed object, the privilege map from the outer operation is applied to the inner operation.
- define managed object A with properties name, description and address.
- define managed object B with properties name, description, date, count.
- define an internal role, granting VIEW, CREATE, UPDATE, DELETE privileges on all properties of object A
- create a new non-administrative user and assign to it the above role
- in access.js, make sure that this user can query and read managed/objectB
- define a postCreate script for managed object A
- inside the postCreate script, issue a query or read of an instance of object B, with fields=* and log the result.
- log in to the enduser UI as the new user
- select managed object A from the sidebar, and click "+ New <ObjectA>"
- fill in the required properties and submit
Result: the logged read of objectB inside the postCreate script returns only those properties that have the same names and are allowed on object A, i.e. name, description and address.
Expected result: the read of object B returns all allowed and requested properties, which in this case should be all since the read is allowed in access.js.
Note: The same happens if privileges are defined and assigned to the user on objectB - they apply as expected when queried separately, but when called from within an outer context, the 'outer' privileges supersede the 'inner' ones.
Note: The actual use case behind this is a delegated admin scenario, where users should be allowed to manage the objects they create. In the absence of an "owned by" privilege filter, we need to create an appropriate role and privileges for the new object on the fly.