[koha-commits] main Koha release repository branch master updated. v3.16.00-264-g54efd3d
Git repo owner
gitmaster at git.koha-community.org
Fri Jul 18 17:11:43 CEST 2014
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "main Koha release repository".
The branch, master has been updated
via 54efd3d17955bfd3a9623d7e7f7ac426786896f8 (commit)
via 3178e7725d3a91435b7363c109d912a9bbe2cea0 (commit)
via 526af4ea075af1da77bf8797c32e855a14329231 (commit)
via d020e0a5a1e22525cf8d0ee8e3f15ac09a7bb9ed (commit)
via 62a08be95b575f0cbc861f44505b06c42283d38c (commit)
from bbc0462a73407116ad9029f4555f6a2f4e817587 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 54efd3d17955bfd3a9623d7e7f7ac426786896f8
Author: Tomas Cohen Arazi <tomascohen at gmail.com>
Date: Fri Jul 18 12:02:41 2014 -0300
Bug 12595: (regression tests)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
commit 3178e7725d3a91435b7363c109d912a9bbe2cea0
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date: Thu Jul 17 13:26:46 2014 +0200
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 at rot13.org>
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 526af4ea075af1da77bf8797c32e855a14329231
Author: Owen Leonard <oleonard at myacpl.org>
Date: Mon Jul 14 14:29:20 2014 -0400
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 at 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 at bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit d020e0a5a1e22525cf8d0ee8e3f15ac09a7bb9ed
Author: Tomas Cohen Arazi <tomascohen at gmail.com>
Date: Fri Jul 11 15:35:27 2014 -0300
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 at hotmail.com>
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 62a08be95b575f0cbc861f44505b06c42283d38c
Author: Dobrica Pavlinusic <dpavlin at rot13.org>
Date: Thu Jul 17 12:27:55 2014 +0200
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 at 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 at bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
-----------------------------------------------------------------------
Summary of changes:
C4/Search.pm | 2 +-
C4/Utils/DataTables/Members.pm | 25 +--
circ/circulation.pl | 4 +-
.../intranet-tmpl/prog/en/includes/circ-menu.inc | 4 +-
.../intranet-tmpl/prog/en/includes/circ-menu.tt | 5 +-
.../prog/en/modules/catalogue/detail.tt | 28 +++-
.../prog/en/modules/members/mancredit.tt | 2 +-
.../prog/en/modules/members/maninvoice.tt | 2 +-
.../prog/en/modules/members/moremember.tt | 3 +-
members/boraccount.pl | 9 +-
members/files.pl | 7 +-
members/mancredit.pl | 12 +-
members/maninvoice.pl | 11 +-
members/member-flags.pl | 10 +-
members/member-password.pl | 9 +-
members/moremember.pl | 4 +
members/notices.pl | 5 +
members/pay.pl | 4 +
members/paycollect.pl | 12 ++
members/purchase-suggestions.pl | 15 ++
members/readingrec.pl | 10 +-
members/routing-lists.pl | 17 +-
members/statistics.pl | 5 +
t/db_dependent/Utils/Datatables_Members.t | 173 ++++++++++++++++++++
tools/viewlog.pl | 20 ++-
25 files changed, 360 insertions(+), 38 deletions(-)
create mode 100644 t/db_dependent/Utils/Datatables_Members.t
hooks/post-receive
--
main Koha release repository
More information about the koha-commits
mailing list