Comment 12 for bug 1736419

I'm adding the results of my testing on a master system loaded with Mike's patch from bug 1730758. This system has a new database with Concerto data. The system also has two new bib records with Located URIs.

There is a small amount of improvement for staff client located URI searches, but I still see significant issues.

* In the public catalog, I am still unable to retrieve any records with Located URIs.
* In the staff client (I was using the web client), the one area where I see improvement is if I am searching totally outside the scope for the located URI's owner (e.g. searching BR3 for a record where the Located URI was owned by BR1), the record is no longer retrieved.
* I retrieve the same results regardless of the state of the opac.located_uri.act_as_copy flag.
   - When the scope is set to the consortium, I retrieve records owned where the located URI is owned by child org units. (unexpected behavior when opac.located_uri.act_as_copy is set to FALSE, expected behavior when opac.located_uri.act_as_copy is set to True).
   - When the scope is set to a system and the located URI is set to a child org unit, I do not retrieve the record (expected behavior when opac.located_uri.act_as_copy is set to FALSE, unexpected behavior when opac.located_uri.act_as_copy is set to True.)

I have not tested this patch on a system with an upgraded database, and I believe Michele's results are a bit different than mine.

This bug is a critical for our libraries. As a result of this bug and bug 1736992, we have postponed a 3.0 upgrade scheduled for next week since these search issues would be a significant regression for users.