Bug 12593: search facets die with regex error if biblio has square brackets in fields

It's quite common to have [something] within facet data, and it produces following error:

Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE

This problem was intoduced in Bug 12151 but is trivial to fix.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Good catch.

To test:
- Created a bibliographic record, linked to an authority record (personal name). Did a search that returned the author as a facet.
- Added a [ symbol to the author name.
- Repeated the search
=> FAIL: "Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE"
- Apply the patch
- Retry the search
=> SUCCESS: No error, bracket shows correctly.

Passes koha-qa.pl too.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12559: Wrong message if all cover images deleted

If a record contains a (one or more) local cover image and it is deleted, a wrong message is presented in the UI.

To reproduce:
 - Have LocalCoverImages set to "Display" and AllowMultipleCovers set to "Allow".
 - Go to the detail page of a record that has no images attached.
 - The 'Images' tab conveniently shows the following message:
   "No images have been uploaded..."
 - Use the "upload" link to add a local cover to the record
 - Complete the process, and "view final record".
 - The 'Images' tab shows the added cover.
 - Delete the cover image using the link below the cover.
=> FAIL: 'Click on an image...' message still shows instead of 'No images have been...'

To test:
 - Apply the patch
 - Repeat the previous steps
=> SUCCESS : 'No images have been...'

Bonus points: previous code didn't show a message at all if the user didn't have
permissions to upload local cover images. I've split the message  in two:
 - 'No images have been...' (for everyone)
 - 'Please upload (link)...' (for those with the right permissions :-D

Regards
To+

Edit: I used JavaScript to inject the 'No images...' message to aid localization.
It can be improved once we fix some stuff in the translation scripts to better support
placeholders/variables in the templates.

Sponsored-by: Universidad Nacional de Cordoba

Signed-off-by: Aleisha <aleishaamohia@hotmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12542: Tabs inconsistency in different circ-menu.inc uses

Differences between circ-menu.tt and circ-menu.inc always crop up when a
new menu item is added--usually only to circ-menu.inc as happened with
Bug 9261.

Other sidebar differences are present due to differences in the patron
data passed by various patron-related script to their templates. This
patch also irons out some of these inconsistencies.

To test, apply the patch and check out to a patron whose record has more
than just basic data: othername, country, patron attributes, street
number, road types, etc. View the following pages and compare the patron
data and visible tabs to confirm that they match:

circ/circulation.pl?borrowernumber=X
members/boraccount.pl?borrowernumber=X
members/files.pl?borrowernumber=X
members/mancredit.pl?borrowernumber=X
members/maninvoice.pl?borrowernumber=X
members/member-flags.pl?member=X
members/member-password.pl?member=X
members/moremember.pl?borrowernumber=X
members/notices.pl?borrowernumber=X
members/pay.pl?borrowernumber=X
members/paycollect.pl?borrowernumber=X
members/purchase-suggestions.pl?borrowernumber=X
members/readingrec.pl?borrowernumber=X
members/routing-lists.pl?borrowernumber=X
members/statistics.pl?borrowernumber=X
tools/viewlog.pl?do_it=1&modules=MEMBERS&modules=circulation&src=circ&object=X

The only difference I've found which is not fixed by this patch is the
display of extended patron attributes in the sidebar of moremember.pl.
This is a piecemeal fix for a problem which really deserves a
centralized solution, but at least it gets us back to consistency for
the moment.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Going through all tabs shows consistency is back. A mid term solution should
implement this in a centralized way. Great job Owen!
No koha-qa errors btw.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12595: Search a patron by his/her firstname and surname

Before bug 9811, if you searched for "John Doe" and only 1 patron with
this firstname/surname existed, the patron detail page was displayed.

Now the result lists all patrons with ( firstname=john or doe ) or (
surname=john or doe). Which is quite annoying when you expect only 1
result.

Test plan:
0/ Create some patrons like: "John Doe", "Jane Doe", "John Smith".
1/ Search for "John Doe" in the patron search box
2/ Verify you got 2 results
3/ Apply the patch
4/ Search for "John Doe" in the patron search box
5/ Verify you are redirected to the right patron detail page.

Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12595: (regression tests)

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>