On Thu, Nov 6, 2008 at 3:57 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote: > Joe Atzberger a écrit : > >> I find the fallback to firstname entirely regrettable and have argued >> against it in the past. I am certain the only accounts in favor of it >> were regarding small libraries where a firstname basis might make sense. > > I disagree ;-) > > It's interesting for large libraries to be able to get the result they > want when they enter "doe john". As entering just "doe" would result in > a large result set. > So I think it's useful for large libraries, more than for small ones ;-) > > However, i'm not against a change here, but I just care about the > useability : atm, the behaviour is quite easy for librarians (except for > the cardnumber=surname case i've already pointed, but it happends only once) > > A can I suggest a solution where the patron would be splitted in 2 parts : > cardnumber or surname : _____________________ > firstname : __________________________ > > that would result in a better SQL, and would not be a pain for the > librarian. I think there's two points being made here:
1. (Galen and Joe): the core API shouldn't have fallbacks on what would normally appear to be a lookup on a unique value. This is primarily a coding standards statement. 2. (Paul): there should be one search box that allows search by barcode, but also falls back to searching by name (which I think most of the community would agree on). So the resolution should probably be to just split up those functions into two API calls to improve the quality of the code. Right? I happen to know for certain that a lot of libraries rely on the single search input box as the way to search for a patron record by barcode and name, and some libraries want to be able to enter in other stuff like telephone number or address in that one input box too -- they prefer not to have to click on Patrons and do an 'advanced search'. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS [EMAIL PROTECTED] |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
