Evergreen

Comment 9 for bug 1847805

Revision history for this message

Galen Charlton (gmc) wrote on 2023-02-15:

Mike and I had a discussion about an alternative implementation and landed on teaching open-ils.pcrud how to automatically filter by permissions along these lines:

- Add an option that's peer to flesh (et al) in PCRUD search call to specify that the query should get filter conditions automatically added to whatever the client has supplied.
- This would include a dedicated function that can generate an appropriate where clause addition ( {$context_field : { 'in' : $perms_at_array }} or { -exists : { $linked_context_subquery }} or, for no-perms required, just TRUE ) to be unconditionally ANDed by inserting {'-and':[$generated,$user_supplied}] above the user-supplied filter hash.
- All this should require is the core class hint and the user context.
- The list of OUs could be generated by a version of permission.usr_has_perm_at_all() that knows how to check multiple permissions at once. Depending on how this performs, it could either be invoked right before running the main query or directly included in the where conditions.
- The most complication will come from the few linked perm contexts that use "jump". hold notification, acq admin, payments/billings, surveys, link checking, and serials are the users of that construct. acq LID in particular specifies 2 "jump"ed context fields and 4 possible perms, so a general solution would have to support multiple OR'd generated filters.
- We should also support the owning_user perm construct, but that seems a natural extension to the above.
- Even the user-object perm map should be easy to support, and since the table behind that in normally empty or tiny, it shouldn't have a performance impact in practice.
- It would be good, rather than doing all the work on every call, to invent pcrud-mode startup logic that generates an appropriate set of check templates for each class. The problem with that is knowing how to stick the user id and org list into all the right places of the cloned perm-checking templates at call time. Likely we can record the jsonPath for those when needed and use jsonObjectFindPath() or findMultiPath[Recurse]() from libosrf_json (osrf_json_tools.c) at call time.

Another thing to look at during the implementation would be to see if adding this permission-based filtering logic can be cheaply done when retrieving rows for fleshing.

Mike and I had a discussion about an alternative implementation and landed on teaching open-ils.pcrud how to automatically filter by permissions along these lines:

- Add an option that's peer to flesh (et al) in PCRUD search call to specify that the query should get filter conditions automatically added to whatever the client has supplied.
- This would include a dedicated function that can generate an appropriate where clause addition ( {$context_field : { 'in' : $perms_at_array }} or { -exists : { $linked_context_subquery }} or, for no-perms required, just TRUE ) to be unconditionally ANDed by inserting {'-and':[$generated,$user_supplied}] above the user-supplied filter hash. 
- All this should require is the core class hint and the user context.
- The list of OUs could be generated by a version of permission.usr_has_perm_at_all() that knows how to check multiple permissions at once. Depending on how this performs, it could either be invoked right before running the main query or directly included in the where conditions.
- The most complication will come from the few linked perm contexts that use "jump". hold notification, acq admin, payments/billings, surveys, link checking, and serials are the users of that construct. acq LID in particular specifies 2 "jump"ed context fields and 4 possible perms, so a general solution would have to support multiple OR'd generated filters.
- We should also support the owning_user perm construct, but that seems a natural extension to the above.
- Even the user-object perm map should be easy to support, and since the table behind that in normally empty or tiny, it shouldn't have a performance impact in practice.
- It would be good, rather than doing all the work on every call, to invent pcrud-mode startup logic that generates an appropriate set of check templates for each class.  The problem with that is knowing how to stick the user id and org list into all the right places of the cloned perm-checking templates at call time.  Likely we can record the jsonPath for those when needed and use jsonObjectFindPath() or findMultiPath[Recurse]() from libosrf_json (osrf_json_tools.c) at call time.

Another thing to look at during the implementation would be to see if adding this permission-based filtering logic can be cheaply done when retrieving rows for fleshing.