Acquisitions Search May Not be Showing Full Results

Bug #1960674 reported by John Amundson
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
High
Unassigned

Bug Description

Evergreen 3.7.2

This is going to be hard to explain, but I'll try my best.

If you are performing a search through Acquisitions > General Search, Selection Lists, Purchase Orders, or Invoice signed in as a user with the various Acquisitions view permissions assigned at a limited depth, (for example, just to their library), then full results may not display.

Here is an easy way to see this on CW MARS data. A similar approach may work on other datasets.

1. Sign into Evergreen as a user with Acquisitions permissions set at the library/town level. For example, just BR3.
2. Go to Acquisitions>General Search.
3. Search on "Line Item - Lineitem ID" - "is NOT" - "1".
4. In my system, no results are displayed. If you increase your row output higher, you might get some results.
5. Add another search term - "Line Item Detail - Owning Library" - "is" - "BR3". [Note that the chosen branch should be where the user has permissions.]

This produces many results for me. While this is one of the easiest searches to test, it's not the only one that is affected.

Essentially what seems to be happening is that the search is ignoring the working location and fetching everything in the system that matches the search terms. Then the part that displays the results is removing everything that doesn't match. It's not, however, updating row numbers.

So if a result would be fourth in the results with universal permissions, no other result is allowed to take over fourth place. Sometimes I can search and limit my results to 25 rows, for example, only get 22 results on the page, but still have more pages to look through. That's because 3 of the first 25 rows are taken up by items I don't have permission to see.

This is very hard to explain and decently difficult to test. It does, however, have the potential to cause a lot of real-world trouble. For example, if a library is cleaning up on-order POs at the end of the fiscal year, they might perform a search and get no results back. They'll think there are no POs left to clean up, but in reality there are.

When I tested the Acquisitions Sprint for the Provider rewrite, I noticed this behavior there, as well. That was fixed during the sprint, so maybe someone from Equinox remembers that and remembers what was done to fix it.

I'm attaching two sets of screenshots where I perform the same search - one that is NOT limited by org unit and one that is.

Set 1 - No results display in the first search. Full set of results appear in the second.

Set 2 - Rows limited to 100 - 9 results appear in first search. Full set of 17 appear in the second.

Revision history for this message
John Amundson (jamundson) wrote :
tags: added: acq
Revision history for this message
Christine Morgan (cmorgan-z) wrote :

Following John's steps on a 3.8 system with production data, I was able to reproduce the behavior described.

I also tried the following:
1. I set the row count to 100.
2. Did the same "Line Item - Lineitem ID - is not - 1" search and again got no result.
3. Clicked the Lineitem ID heading a couple of times to do a descending sort and got only 10 results.

A more practical example:
1. Row count set to 100.
2. In the Line Item Search tab, searched for "Line Item - Cancel Reason - is - Delayed: Backorder". No results were found.
3. Did a descending sort on Lineitem ID and got 55 results.

Since this is an issue with financial implications it would be good if this could be addressed quickly.

Changed in evergreen:
status: New → Confirmed
Changed in evergreen:
importance: Undecided → High
Revision history for this message
Michele Morgan (mmorgan) wrote :

Working with Christine to confirm this but, we came up with a database query that clarified the issue in our system.

SELECT ou.shortname, cr.label
FROM acq.lineitem li
JOIN acq.purchase_order po ON li.purchase_order = po.id
JOIN actor.org_unit ou ON po.ordering_agency = ou.id
LEFT JOIN acq.cancel_reason cr on li.cancel_reason = cr.id
ORDER BY li.id
LIMIT 100

Comparing the Lineitem ID is not 1 search sorted by the Lineitem ID with the query results, we saw 49 rows in the grid in the client. The grid was limited to 100 rows.

Our query results had 49 rows out of the 100 retrieved where the ordering agency matched the workstation location.

This result agrees with John's description:

"Essentially what seems to be happening is that the search is ignoring the working location and fetching everything in the system that matches the search terms. Then the part that displays the results is removing everything that doesn't match. It's not, however, updating row numbers."

Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

Sounds like it's related to this bug from the beginning of acquisitions - https://bugs.launchpad.net/evergreen/+bug/884991

Revision history for this message
Kathy Lussier (klussier) wrote :

It also reminded me of this old acq bug - https://bugs.launchpad.net/evergreen/+bug/731510

Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

We are seeing this in 3.11.1

tags: added: regression
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.