[OPENIDM-15473] Return custom _refProperties fields in virtual properties Created: 14/Sep/20 Updated: 14/Jan/21 |
|
Status: | Open |
Project: | OpenIDM |
Component/s: | Module - Managed Objects, Module - Relationships |
Affects Version/s: | 7.0.0 |
Fix Version/s: | None |
Type: | Improvement | Priority: | Minor |
Reporter: | Tim Vogt | Assignee: | Dirk Hogan |
Resolution: | Unresolved | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Target Version/s: | |
Epic Link: | Better Living through RDVPs |
Description |
Currently, virtual properties can be configured to return a specified set of, or all, properties of the targets object(s). Otherwise, if none are specified, the _ref, _refResourceId and _refResourceCollection attributes of the relationship object itself are returned, however any custom _refProperties fields are not. Making the latter available, perhaps in a configurable manner, would be extremely useful to allow for policy decisions or DA privilege filtering based on qualified relationships. For example, in typical business use cases, objects of type 'organisation' usually have regular members, org admin members (can admin the organisation itself) and user admin members (can admin other members of the org, but not the org itself). If we want to allow a user to be a member of multiple organisations and have different admin status and corresponding DA privileges per org, we can currently only achieve this by maintaining separate relationship properties plus corresponding virtual properties for each type of membership (i.e. "memberOf" , "adminMemberOf", "userAdminMemberOf"). With the proposed enhancement, we could model the type of membership as a (set of) attribute(s) of the memberOf relationship, return it as part of the virtual property and use it directly in the privilege filter, reducing the requirement to only one relationship property. This would also turn _refProperties into a much more powerful instrument, since we could use them directly as a condition in AM policies or, say, throttling filters in IG. Currently, multiple lookups would typically be required to achieve the same . |