Teach Angular combobox to filter PCRUD searches by permitted OUs

[Galen Charlton]

As there is no server-side solution yet for bug 1847805, I propose a client-side amelioration to the problem that a eg-combobox that does a PCRUD retrieval of entries can fail to include rows that the user is permitted to access.

I note bug 1999544 as an example of this: while the patch that was pushed ameliorates the problem in cases when ordering for a single branch or where funds are owned only at the system level and above, I am concerned that it can artificially limit the set of available funds when doing centralized ordering that uses decentralized funds. Specifically, the set of funds that a staff user may be permitted to see may extend well past the funds visible to their workstation and its ancestors.

To square the circle, I propose adding an option to eg-combobox that would specify adding a filter based on the OUs that the user has retrieval permission for. Specifically, it might do something like this:

- Check to see if retrieval permission is tied to an OU (i.e., isn't global_required per the IDL). If so, continue on; otherwise, just do the PCRUD search normally.
- Get the list of OUs at which the staff user has retrieval permission. A new method wrapping permission.usr_has_perm_at_all() would be needed.
- Construct a query clause that limits the retrieved rows by OUs. If the OU check is simple (i.e., the IDL specified a context_field), that's straightforward. If it's instead a foreign context (via <context link...), the clause would need to be the JSON query equivalent of a WHERE field IN (SELECT ...)
- Combine the filter clause with any other query elements using "-and"
- Run the query.

This approach would ignore object-level permissions, but 99% of the time they don't matter.

This would allow more precise filtering of queries to populate the eg-combobox with less need for hand-constructed filter conditions that may not have the right semantics.

Evergreen master

[Galen Charlton (gmc)]

Noting that it would probably be a good idea to NOT turn on such an option across the board, as in some cases the result SQL queries might need tuning.

[Tiffany Little (tslittle)]

I need more coffee to follow the main thought thread, but fwiw we've been running the fix for that bug in production since our upgrade in January. We do have one library that has a system-level orderer but uses decentralized funds, so I felt *sure* that you were wrong but upon investigation found that no, you're right. :) So marking this Confirmed. But then I had to wonder why it's not an issue for us, and so here's my thoughts on our use case.

We have a SYSTEM-ACQADMIN perm level that has a VIEW_FUND at system level. So this orderer has access in fund administration to all funds because she's the one who manages the money. However, she only does ordering for one branch. So in her dropdowns, she only really wants to see the funds for the branch she's ordering for.

In cases where there's true centralized ordering, we don't use decentralized funds even if they're ordering for multiple locations. The main reason we came to that standard is because of the Load MARC Order Records interface. You have to set an Ordering Agency in the form, but if you're uploading funds in your holdings data and those funds have multiple owning orgs, you're going to get errors because EG can't match up the Ordering Agency in the form with the owning org in the funds. So with centralized ordering, we set all funds as owned at the system level and then in the fund code it will indicate the branch. The thought process behind where a fund is owned is "who is ordering this?" For decentralized ordering, it's the branch, so they only want to see their own branch's funds. For centralized ordering, the system is ordering, so the funds are owned by the system.

[Galen Charlton (gmc)]

I think another consideration is whether attributes like the PO ordering agency or the line item copy's owning library should be used to filter the set of available funds. Ultimately, zeroing in the right answer in the specific case of the funds drop-down may need to be spun off into a separate bug, but I think the notion of teaching eg-combobox to pre-filter by permitting OUs has wider applicability.

[Tiffany Little (tslittle)]

There is a wishlist bug for optionally limiting funds based on the copy owning library--bug 1994985. But the point is well taken that that's a thought for another day.