Activity log for bug #2007322

Date Who What changed Old value New value Message
2023-02-14 23:15:21 Galen Charlton bug added bug
2023-02-14 23:15:27 Galen Charlton evergreen: importance Undecided Wishlist
2023-02-14 23:19:01 Galen Charlton description 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 that 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 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
2023-02-15 13:13:56 Tiffany Little evergreen: status New Confirmed
2023-02-15 13:14:01 Tiffany Little tags angular
2023-03-16 15:43:45 Christine Morgan bug added subscriber Christine Morgan