To reproduce: 1) * Put a borrower's name in the box * Leave the other two fields as "any" * This works correctly 2) * Put a borrower's name in the box * Set the "Library" field to a library, the "Category" field as "any" * This provides you all the borrowers in that library, ignoring the borrower's name. 3) * Repeat the above with a category set. * Note that the category doesn't affect the output at all.
Created attachment 4506 [details] [review] Bug 6513 - make the routing list search work properly, and faster too.
Created attachment 4507 [details] [review] Bug 6513 - ensure the subscription ID gets carried across
Created attachment 4870 [details] [review] [Signed Off] Bug 6513 - make the routing list search work properly, and faster too. Signed-off-by: Liz Rea <lrea@nekls.org>
Created attachment 4871 [details] [review] [Signed Off] Bug 6513 - ensure the subscription ID gets carried across Signed-off-by: Liz Rea <lrea@nekls.org>
SQL in FindPartialName is unlimited, which could cause system slowness for large databases and generic queries. For this reason I mark it as Failed QA. The addition of a third patron search subroutine is counter to bug 6253, which is a sponsored change to bring Search and SearchMember together into a single, robust search routine. I would prefer to see the search for patrons in the serials routing list area use the same search routine as everywhere else (with different parameters passed as necessary), but I solicit community feedback on this. Should another patron search subroutine be allowed, if it solves this particular issue?
I confirm the search is still broken on current master, changing version to reflect this. Attached patches do no longer apply.
It would make the most sense for this to be modified to use existing patron search stuff, if it's possible for that to have filters too (or, we could apply the filters post-hoc I guess.)
This is still valid.
Bug 13021 and bug 12648 use the member search webservice. When they will be pushed, maybe this one will be easy to implement using the same way.
Erg, which I'd noticed this earlier, it would have been very easy to slap a 'LIMIT 20' or something onto the SQL. However now it probably doesn't apply.
Should have been fixed by bug 13891. *** This bug has been marked as a duplicate of bug 13891 ***
commit a77a9a70a232c3b2839945638df0f73aa9610327 Bug 13891: DataTables server-side processing - Serial recipients