[koha-commits] main Koha release repository branch master updated. v3.14.00-315-ga776c77
Git repo owner
gitmaster at git.koha-community.org
Fri Jan 17 06:04:05 CET 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 a776c7764050290d20ad4e5200aaed11a3983bf7 (commit)
via d211fa50ede180ed511cdf7f55be6c084abc1ff5 (commit)
via 38edd714c598322e81a32a0dfc5f2ce0da46826d (commit)
via a23d4181b1e756a61a036059b8b909d4f0d30537 (commit)
via 92be11bbcf20628dd7db8b83fc0b902ba578a28a (commit)
via 1a9737be768aa1e585addc596e2fcb5a77482c38 (commit)
from e686dd25438b66de751551c8f8fecff115b661d4 (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 a776c7764050290d20ad4e5200aaed11a3983bf7
Author: Galen Charlton <gmc at esilibrary.com>
Date: Fri Jan 17 05:21:07 2014 +0000
Bug 9788: (follow-up) update the bootstrap theme
This patch applies the change made in the QA follow-up
to the Bootstrap theme.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
commit d211fa50ede180ed511cdf7f55be6c084abc1ff5
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Thu Sep 26 12:22:51 2013 +0200
Bug 9788: (follow-up) Unit tests for changed routine GetReservesFromItemnumber
Adds three tests to Reserves.t for GetReservesFromItemnumber.
We test if this routine does not return a future next available hold,
a future item level hold. And if it does return a future wait (that is:
a confirmed future hold, using ConfirmFutureHolds).
Note that Holds.t does also contains some basic tests for this routine,
but the additional tests seem to better located in the direct context of
tests for bug 9761 for ConfirmFutureHolds.
Test plan:
Run both t/db_dependent/Holds.t and t/db_dependent/Reserves.t.
Verify if both tests do not fail.
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
commit 38edd714c598322e81a32a0dfc5f2ce0da46826d
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date: Mon Nov 4 11:55:57 2013 +0100
Bug 9788: QA followup
1/ CURRENT_DATE() is a MySQLism and should be replaced with CAST(now() AS
DATE).
2/ The date formatting should be done in the template (using the TT
plugin).
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
commit a23d4181b1e756a61a036059b8b909d4f0d30537
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Fri Jun 21 18:43:59 2013 +0200
Bug 9788: (follow-up) for expirationdate in Letter.pm
Pasting comment from the Bugzilla report:
Looking bit longer at this code, it is kind of strange to find it
there in the first place. Adding maxpickupdelay in Letters.pm should
not be there, but it is..
Also this date is not used normally in the default HOLD Available for
Pickup notice (that we are generating in this case). And if it would be
undef, the expiration date should imo be empty instead of today+0.
(before adding maxreservespickupdelay, you should test the allowexpire
pref first) So it is an (invisible) bug on its own.
Test plan:
See former patch. Kyle just discovered this bug, apparently by
deleting the maxpickupdelay pref..
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
commit 92be11bbcf20628dd7db8b83fc0b902ba578a28a
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Thu Sep 26 10:33:46 2013 +0200
Bug 9788: (follow-up) removing the alldates parameter from GetReservesFromItemnumber
Before bug 9788 the alldates parameter of GetReservesFromItemnumber was
actually not used in the codebase.
The first patch of bug 9788 did change that and passed true by default.
But a closer look revealed that we do not really need it.
The parameter is removed by this patch; the SQL statement is slightly
adjusted: if reservedate<=now or a waitingdate is filled for the
requested itemnumber, GetReservesFromItemnumber will return the reserve.
This includes so-called future waits: a future hold that has been confirmed
ahead of time with pref ConfirmFutureHolds > 0 days.
Note that future item-level holds are not really interesting to return; this
just corresponds to original behavior. Future next-available holds are not
in view at all; they do not contain an item number.
Test plan:
Actually, the test plan of the first patch is valid. But for completeness I
repeat it here:
[1] Enable future holds and set ConfirmFutureHolds to 2 days.
[2] Place a future next-available hold for 2 days ahead.
[3] Check item status on catalogue detail. Available? That is fine.
[4] Confirm the future hold by checking it in. ('future wait')
[5] Look at item status again on catalogue detail. Must be Waiting now.
[6] Switch to OPAC and login as another opac user. Goto Place a hold.
[7] Check item status with item level hold info. Is it waiting?
[8] Try to place hold in staff, check item level status again. Waiting?
[9] Make a transfer for the item. Switch branch. Check hold status on
Transfers to receive.
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
commit 1a9737be768aa1e585addc596e2fcb5a77482c38
Author: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Date: Mon Mar 11 14:28:57 2013 +0100
Bug 9788: Improvements when calling GetReservesFromItemnumber
This patch makes GetReservesFromItemnumber also returns the waiting
date and removes some repeated code.
Improves item status display on catalogue detail, when placing a hold at
opac-reserve and in staff, and on transfers to receive form.
This patch builds on work from reports 9367 and 9761.
Test plan:
Place a future next-av. hold (enable future holds prefs), say 2 days ahead.
Check item status on catalogue detail. Nothing to see.
Enable ConfirmFutureHolds by inserting a number of days, say 2.
Confirm earlier hold by checking it in. Look at item status again on detail.
Switch to other opac user. Try to place a hold again. Check item status with
item level hold info. Try to place hold in staff, check item level status.
Make a transfer for that item. Switch branch. Look at transfers to receive.
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
-----------------------------------------------------------------------
Summary of changes:
C4/Letters.pm | 10 ++++---
C4/Reserves.pm | 21 ++++++++-------
catalogue/detail.pl | 14 ++++------
circ/transferstoreceive.pl | 2 +-
.../prog/en/modules/catalogue/detail.tt | 3 ++-
.../prog/en/modules/reserve/request.tt | 2 +-
.../opac-tmpl/bootstrap/en/modules/opac-reserve.tt | 3 ++-
.../opac-tmpl/prog/en/modules/opac-reserve.tt | 3 ++-
opac/opac-reserve.pl | 21 ++++++---------
reserve/request.pl | 11 ++------
t/db_dependent/Reserves.t | 28 +++++++++++++++++++-
11 files changed, 68 insertions(+), 50 deletions(-)
hooks/post-receive
--
main Koha release repository
More information about the koha-commits
mailing list