Currently if a user reads their own _id with relationship fields they are granted that access through router-authz.js and they see all of their properties and are also allowed (through relationshipFilter#filterResponse) to see "_notifications", "_meta", and "idps".
Now that DelegatedAdministration is allowing relationships:
- The DA user should see all of their properties even if privileges don't grant it (just as before), for example if "userName" is not listed in any privilege attributeTypes for VIEW permission, the user should still see their own "userName"
- The DA user should also see any additional relationships they have privileges to VIEW outside of "_notifications", "_meta", and "idps" (such as "authzRoles").
There is currently a conflict between this working though because there is some sort of expectation of allowing all main properties are outside of privileges, but including relationships that are in privileges.
Additionally, access.js & router-authz.js is currently evaluated first, and if it succeeds, DelegatedAdminFilter is not even invoked to evaluatePrivileges. How should DelegatedAdminFilter be aware of this "own user" scenario?
EDIT - approach:
Origin properties do not need privileges. Relationships access directly through an edge request, through request fields, and through body attributes (such as during a patch) do need privileges.
The approach should be to implement the current access rules through a DelegatedAdmin RequestVisitor along with adding support for relationship fields filtered by privileges.
- Access rules removed - Should work for origin, relationships and edge.
- Access rules left in place - Should work for relationships and edge with original rules handling origin requests.
- Document how to move/update to DAF handling origin ownData from using access rules. -> remove access rules, enableDynamicRoles : true, ...
- Determine precedence of schemaConfig such as isViewable/userEditable over privileges that have permission otherwise.