OPENIDM-13657 removed queryIds, including find-relationships-for-resource, which returns the edges issuing out of a given vertex via a specific relationship field. This query was used for 'internal' purposes, including:
- effectiveRoles.js - queries the edges issuing out of a managed user's role array - necessary to generate the effectiveRoles and effectiveAssignments arrays returned any time a managed user is read
- conditional grantor/grantee processing - to determine the existing set of direct and/or conditional grants necessary to update grantor/grantee conditional relationship fields
Query ids for which link-expansion was enabled were added to the validInRelationshipQuery array. Note that find-relationships-for-resource was not added to this array, so queries specific to the 'internal' purposes enumerated above never incurred link expansion, even if they were dispatched as part of a request which included fields which would normally result in link expansion.
OPENIDM-13657 and the removal of queryIds, these 'internal' queries are indistinguishable from 'normal' user queries. See https://stash.forgerock.org/projects/OPENIDM/repos/openidm/pull-requests/5640/diff#openidm-runtime/src/main/resources/bin/defaults/script/roles/relationshipHelper.js
for detail on the replacement of find-relationships-for-resource queryId against the relationship endpoint with queryFilter=true against the same endpoint for details. See
for detail on changes to how find-relationships-for-resource and its replacement are handled in the relationship endpoint.
Because the repo layer determines link expansion via request fields transferred to either the OriginResourceContext or the RelationshipSchemaContext, the generic handling of 'internal' queries will incur link expansion.
As a result, certain requests will unnecessarily incur the link-expansion overhead for the 'internal' purposes described above. For example, the update of a given managed user with a request which specifies fields of _ref will incur link expansion as part of the calculation of effective roles and effective assignments. Or, the update of the condition defined in a conditional grantor (role) will incur link expansion in the query which determines existing direct grants.
It would be possible to more selectively specify which requests were to be link-expanded by removing the field specification which triggers this expansion from the OriginResourceContext and the RelationshipSchemaContext, and return them to the Request instances. This way, the Context object corresponding to a given user request, a request which specifies link expansion, would not pollute all 'internal' queries made in the context of realizing this user request.