In high traffic environments with large numbers of patrons, empty patron searches can take a very long time and cause over-use of resources. It would be good to have the option to require search criteria for patron searches.
Created attachment 188111 [details] [review] Bug 41048: Add ability to disallow empty patron searches In high traffic environments with large numbers of patrons, empty patron searches can take a very long time and cause over-use of resources. It would be good to have the option to require search criteria for patron searches. Test Plan: 1) Apply this patch 2) Restart all the things! 3) Enable DisallowEmptyPatronSearches 4) Browse to any patron search form ( such as members-home.pl, or the one on acqui/basket.pl ) 5) Note the search button is disabled when the search is empty, and enabled which the search box contains text
This works for the search_patron_filter input, but it's not exactly as describe in the DisallowEmptyPatronSearches preference. Don't require/Require at least one search criterion when searching for patrons. I think that category code and branch code filters should count as search criteria. I often use an empty search with those two filters so that would discourage me from using this preference even though I appreciate the need for conserving resources for better performance. Would it be reasonable to enable the button on changing one of these filters too? categorycode_filter, branchcode_filter Also on the aquisitions basket manager search there are a couple other search filters: sort1_filter sort2_filter
Do we really need to controller-side changes? Preventing the submission of the form client-side seems sufficient to me, unless you want to also deal with third-party apps? Tests to cover the API changes are missing, as well as Cypress tests that are required for patron searches.
(In reply to Jonathan Druart from comment #3) > Do we really need to controller-side changes? Preventing the submission of > the form client-side seems sufficient to me, unless you want to also deal > with third-party apps? > > Tests to cover the API changes are missing, as well as Cypress tests that > are required for patron searches. Yes, the server side changes are necessary due to third party API access. I'll wee what I can do about the unit tests!
- Noting test plan doesn't mention the database upgrade needed. - The "Search" button remains disabled even when "Category" or "Library" selected which I think would count as "at least one search criterion". I frequently will do an empty search for all staff members for instance. - "Search patrons" in the header search is totally broken for an empty search. "Processing..." graphic stays on the screen and console reports a "501 (Not Implemented)" error. - If you use the header "Search patrons" search, you can configure an empty search with a Category or Library filter, and it'll work. It will then cause the left hand "Search for patron" to have Category or Library populated with an enabled Search button which is contradictory to the behaviour when navigating straight to "Patrons" and trying to use the left-hand "Search for patron" search form. (I'm guessing that maybe this one needs to rely on Bug 41040 as well? Although I'm not convinced that Bug 41040 is a good idea yet...)
(In reply to Brendan Lawlor from comment #2) > I think that category code and branch code filters should count as search > criteria. I often use an empty search with those two filters so that would > discourage me from using this preference even though I appreciate the need > for conserving resources for better performance. > > Would it be reasonable to enable the button on changing one of these filters > too? > categorycode_filter, > branchcode_filter Glad to know I'm not the only one who does this!