comments: 
* Perhaps a search on mobile would be a nice addition as well? Might as well hit all of the available phone numbers. :)
* limits by library and patron category still work with this patch in place.
* for usability, it might be nice to have the type of search "stick" - so if you select phone for a search, it will stick on phone until you change it to something else. Not completely necessary, but worth thinking about (I'm thinking of a scenario where you type in a phone number, for example, and typo it, and have to do another phone/email/borrowernumber search right away - is that fringe or not?). Maybe a tickbox for "save this search configuration" that would save the field, branch, and patron category options for the session (or until the box is unticked).

* with this patch you still have to search the phone number exactly as it would appear in the record. This either requires that we enforce a format for phone numbers (or do some kind of conversion - but that kid of thing is stinky for i18n). Mickey suggests searching by last 4, which would make sense in the US but might be different in other parts of the world. I'm not sure how to reconcile it. I don't think this is a show stopper for the feature though, it may be as easy as telling staff 'do it like this: xxx xxx xxxx for easy searching.'

* search by borrowernumber is a nice feature, works.
* search by email is a nice feature, works.

I'm prepared to sign off on this with the addition of the mobile to the phone fields searched.

Liz,

I searched with they symbols and without the symbols for the phone number and it worked. The number was (212) 555-1212 and I searched with (212) 555 and then 212 555 and both back up with results - searching for 212555 did not.  

Also, there is no Mobile phone field anymore - there is a primary and secondary phone field - so are you asking for phone to search both those fields, or have two phone searches.  

I'd say this adds a start of the new feature and could be improved, but it's more than we ever had before.  Hence my sign off.

Nicole

Nicole,

In the database the field is called "mobile" not "secondary." It is only called secondary in the interface - the database field name didn't change.

I did not have the same experience as you searching the phone numbers. I will try it again.

Liz

I just tested this again, I cannot make it work as you described. I have exactly the same phone number in my db and none of your variants worked, it only worked when searched exactly as entered.

ok that is crazy, I just went back to check it yet again, and this time it worked - same process, same db, same everything.

I'm trying to track down what the situation is that makes it *not* work because I definitely saw it not working.

well I can't seem to replicate what I saw, so either there's a specific way I did things, or the lack of sleep is getting to me.

I'll sign off if it's got the secondary/mobile added to it - I don't think that's a scope creep, that's a necessary part of the feature.

Simple patch to pass a localized scope to patron searching.  Can be hidden with JQuery if desired.  Marking Passed QA.

For further discussion:  it seems like there is a real need for an Advanced Patron Search, for when people need to start on more than just one non-standard axis at a time.  This would be analogous to the Advanced Search we have for biblios; there would still be a quick search, but also the option to dig deeper.

Thanks for adding the mobile field, kyle.

QA comment:

sorry, but this patch fails rule HTML4 of our coding guideline, see
http://wiki.koha-community.org/wiki/Coding_Guidelines#Upper_and_Lower_cases_in_strings

Please resubmit a patch with lower cases : "Search fields:" instead of "Search Fields:"

New patch submitted to take into account the guidelines pointed out by Paul.

I think a follow up patch would perhaps be better in such cases? It's easier to test the change and you can trust the original patch to not contain any other unintended changes, so it can keep the sign-off for the functional part.

(In reply to comment #15)
> New patch submitted to take into account the guidelines pointed out by Paul.

Kyle I was just giving an example. There are other capital cases, like Borrower Number, Phone Number, Order By, 

There's also an E-Mail, I don't know if it's valid or should be E-mail, you're english native, you'll know.

About katrin comment = it could have been a follow-up, but this one is also valid (& i'll take care immediatly once it's signed-off)

New patch covers the rest of the capitalization problems. 'Order By' was already in the system, so don't blame me for that one ; ) I fixed it anyway. I went with Email, as that seems to be the most widely accepted variation of the word.

Testing notes:

I went through my usual testing for this -- 

Borrower Primary Phone number = (212) 555-1212

Relevant patron data from borrowers:
     borrowernumber: 19
        cardnumber: 23529000035676
           surname: Acevedo III
         firstname: Henry James
           address: 4345 Library Rd.
              city: Springfield, MA
           zipcode: 44224
             email: acevedo@hotmail.com
             phone: (212) 555-1212
            mobile: 222 222 2222
          emailpro: acevedo1@gmail.com
          phonepro: 111-111-1111
           B_email: acevedo2@yahoo.com
           B_phone: (333) 333 3333
       dateofbirth: 1958-05-30
        branchcode: MPL
      categorycode: S
      dateenrolled: 1990-09-23
        dateexpiry: 2020-12-31
               sex: F
             flags: 1
            userid: acevedo
   altcontactphone: 444 4444

Works:
Phone:
(212) 555-1212
(212) 555
212 555
555 1212
Email: 
user@host.com 
user

Doesn't work:
555-1212 
5551212 
(333) 333 3333 (this was exactly what was in the db, and didn't work)
2125551212 (the above are important! They have to work!)
212-555 (maybe ok)
Email:
host.com (or anything after the @ sign. Maybe no big deal)

It gets stickier when the phone numbers aren't in (xxx) xxx-xxxx format. 

If we can't make these work, we will need to document that you must, at a library staff level, define an input pattern and stick to it. That's fine by me - but I think it would be better if it could also search by last 7.

I talked to Kyle about this briefly - 

Documentation should note that phone searches should be searched only on the numbers of a phone number, and separate the area code and exchange with spaces, regardless of how the number is entered in the database.

So no dashes or parens, last 7 only with spaces.

Based on this criteria, this passes. 

Signed off patch incoming.

Created attachment 7777 [details] [review]
Bug 7544 - Add ability search borrowers only on email / phone

This commit adds a new pulldown field to the patron quick search.
This pulldown "Search Fields" can have any number of field combinations
to search on. The combinations added in this commit are:

Standard: Default, searches on original fields
Email: Searches on email, emailpro, and B_email
Borrower Number: Searches on borrowernumber
Phone Number: Searches on phone, phonepro, B_phone, altcontactphone, and mobile

Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>

Tested by running searches on all the new fields, and the old fields
with limits on branch and category. The seach on phone number could be
a bit more inclusive, but it works with and without symbols so I
give my sign off on this patch.

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Documentation should note that phone numbers should be searched only on the
numbers of a phone number, and separate the area code and exchange with spaces,
regardless of how the number is entered in the database.

So no dashes or parentheses in the phone search, and the last 7 search works with spaces, i.e. xxx xxxx.

Double checked for i18n considerations - most phone numbers should be searchable with this.

QA comment: this time, nothing to say !