As a developer writing a search or other batch retrieval endpoint, I'd like to be able to utilize database paging so that I don't first have to pull all my elements from the database, convert them to Java objects, iterate through each of them filtering out the ones my user doesn't have permissions on, and then returning that final list in a very non-performant way.
establish a pattern whereby "enough" of the objects required rights are stored with the object (table entity), so that a JPAQL/SQL statement may be written given which filters out table rows based on the user's rights.
works with our current definition of Supervisory nodes, groups, facilities, role assignments, etc
establish this pattern so that other Services than the Requisition service may learn from it. (e.g. Fulfillment).
This looks good. At the end of this work, Requisition View's performance has improved approx 3x.
Moved this to done, skipping QA, as this would be difficult to verify from the UI.
and FYI. There is a potential for regression on the requisition view screen, primarily.
I need to do a bit more stuff on this (documentation), so moving back to In Progress for that.
Regarding what Josh mentions about possible regressions on the Requisitions > View screen, has anyone already re-tested that screen or could we schedule a manual check of it soon?
The documentation you added (the last 2 commits) look good to me. All the previous commits (other than the documentation) were already reviewed in Fisheye and marked Done.
So I believe the only thing remaining on this ticket is a final bit of manual testing. Moving to for this QA noted in the comments above.