[koha-commits] main Koha release repository branch 3.16.x updated. v3.16.09-12-g11b5c4b
Git repo owner
gitmaster at git.koha-community.org
Wed Apr 22 14:20:45 CEST 2015
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, 3.16.x has been updated
via 11b5c4b10ad02f24c82886a0103948ca9993ea89 (commit)
via 3b3726ea4ca4d6f0f33acebed0462f2b93f35471 (commit)
via 174c0899d47dcbc143c60c303e2d85a635650f99 (commit)
via f02eb7a831c21140683eca4f955460ffe02396f0 (commit)
from 40b2587164d8b40294aeabebc1412000ef64d4da (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 11b5c4b10ad02f24c82886a0103948ca9993ea89
Author: Frédéric Demians <f.demians at tamil.fr>
Date: Mon Jan 12 12:18:19 2015 +0100
Bug 13568 OAI Server doesn't handle properly resumption token
When responding to ListRecords and ListIdentifiers verbs, OAI server doesn't
return proper resumption token. At the end of a result set, OAI server
generates a resumption token even if there isn't anymore records. Consequently,
OAI harverster will send a new request, based on this invalid resumption,
token. OAI Server responds with an empty resultset, which is considered as an
invalid response by most of the harvesters.
TO TEST:
- Find in your DB, a day where a few biblio records have been created. The
number of created biblios must inferior to OAI-PMH:MaxCount.
- Let say this day is 2014-01-09. Send an OAI-PMH request to Koha OAI Server:
/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml&from=2014-01-09&until=2014-01-09
- At the end of the result, you will see a resumption token which looks like that:
<resumptionToken cursor="47">marcxml/47/2014-01-09/2014-01-09/</resumptionToken>
This is wrong. No resumptiion token should be sent since there isn't anymore
records to harvest.
- Apply the patch.
- Resend the OAI-PMH request. There is no resumption token at the end of the
result.
- You could test also with ListIdenfiers verb in place of ListRecord.
Signed-off-by: Christophe Brocquet <christophe.brocquet at obspm.fr>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
commit 3b3726ea4ca4d6f0f33acebed0462f2b93f35471
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date: Wed Jan 28 08:31:30 2015 -0500
Bug 13636 - Staff search results item status incorrect for holds
Imagine this scenario: we have one record with four items. Two of those
items are checked out, one of those items is a waiting hold, and one of
those items is available. We would expect to see this on the search
results page. Instead, we will see both non-checked out items as
unavailable due to waiting holds.
This is due to a semantic issue GetReserveStatus.
C4::Search::searchResults uses GetReserveStatus to get the reserve
status of each item, but unlike all other calls to the sub, this one
passes in not only itemnumber, but biblionumber.
When no reserve is found for the available item, the subroutine uses the
biblionumber to grab what is essentially an arbitrary reserve to use for
the status. This makes no sense and this functionality should be
entirely removed from the subroutine so regressions like this will be
prevented in the future.
Test Plan:
1) Create one record with 4 items
a) check two of the items out to patrons
b) set one of the items as a waiting hold
c) leave the fourth item as available
2) Run a search where this record will be in the results list
3) Note that the results list 2 items on loan, two unavailable
4) Apply this patch, reload the search results
5) Note that the results list 1 available, 2 on loan, 1 unavailable
Signed-off-by: John Andrews <jandrews at washoecounty.us>
Signed-off-by: Sheila Kearns <sheila.kearns at state.vt.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Note: This is for the staff search result list!
Works as expected.
commit 174c0899d47dcbc143c60c303e2d85a635650f99
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date: Wed Nov 19 08:16:17 2014 -0500
Bug 13298 - Holds ratios report ignores ordered items
The holds ratio report ignores ordered items. This could cause a library
to inadvertently order more copies of a title than they actually need.
An option should be added to count ordered items ( i.e. any negative
notforloan value ).
Test Plan:
1) Apply this patch
2) Create a record with two items, one regular, one ordered.
3) Place 3 holds on the item
4) Run the reserve ratios report, by default you should see this record
5) Check the new 'include ordered' checkbox, rerun the report
6) Note that record is no longer displayed
Signed-off-by: Heather Braum <hbraum at nekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
commit f02eb7a831c21140683eca4f955460ffe02396f0
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date: Mon Nov 17 17:17:49 2014 +0100
Bug 13270: Don't display "vendor note" label if nothing to display
Bug 12111 removes the vendor note edition on receiving.
The label should not be displayed when it's empty.
Test plan:
1/ Receive an order without a vendor note and verify that the label is not
displayed.
2/ Receive an order with a vendor note and verify that the note is
displayed.
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
Works as described, small template change.
-----------------------------------------------------------------------
Summary of changes:
C4/Reserves.pm | 12 +---
C4/Search.pm | 2 +-
circ/reserveratios.pl | 11 ++--
.../prog/en/modules/acqui/orderreceive.tt | 4 +-
.../prog/en/modules/circ/reserveratios.tt | 39 +++++++-----
opac/oai.pl | 64 +++++++++++---------
6 files changed, 75 insertions(+), 57 deletions(-)
hooks/post-receive
--
main Koha release repository
More information about the koha-commits
mailing list