[koha-commits] main Koha release repository branch 3.14.x updated. v3.14.09-3-g71efba2

Git repo owner gitmaster at git.koha-community.org
Fri Aug 1 14:56:11 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, 3.14.x has been updated
       via  71efba230442c583d591f8107874cb10016c096a (commit)
       via  21e5cccc6e07fc04c773f0549182127f40aa9395 (commit)
      from  183aa49e6b646407f3ebb594de738ca34197b4fa (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 71efba230442c583d591f8107874cb10016c096a
Author: Galen Charlton <gmc at esilibrary.com>
Date:   Mon Apr 14 18:44:07 2014 +0000

    Bug 12079: ensure that CheckReserves() includes reserve_id in its response
    
    This patch modifies _Findgroupreserve so that its one caller,
    CheckReserves(), would include the reserve_id field in the
    hold request it returns.
    
    Failure to include reserve_id in every circumstance resulted
    in bug 11947.  This patch is therefore a complementary fix for
    that bug, but is not meant to preempt the direct fix for
    that bug.
    
    To test:
    
    [1] Verify that t/db_dependent/Reserves.t passes.
    [2] Verify that the following test plan taken from
        the patch for bug 11947 works for this patch
        *without* applying the patch for 11947:
    
    * have a few borrowers, say 4.
    * have a biblio with a single item (you can scale this up, it should
      work just the same.)
    * issue the item to borrower A
    * have borrowers B, C, and D place a hold on the item
    * return the item, acknowledge that it'll be put aside for B.
    * view the holds on the item.
    
    Without the patch:
    * the hold priorities in the UI end up being "waiting, 2, 1" when they
      should be "waiting, 1, 2".
    * in the database "reserves" table, they're really "0, 2, 3" when they
      should be "0, 1, 2".
    
    With the patch:
    * the hold priorities in the UI end up being "waiting, 1, 2"
    * in the database, they're "0, 1, 2"
    
    Signed-off-by: Galen Charlton <gmc at esilibrary.com>
    Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel at gmail.com>
    
    Work as described. No koha-qa errors. Test pass
    
    Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
    Signed-off-by: Galen Charlton <gmc at esilibrary.com>
    (cherry picked from commit 695fdebdee802387f45505a1350120727d3e2f7f)
    Signed-off-by: Fridolin Somers <fridolin.somers at biblibre.com>

commit 21e5cccc6e07fc04c773f0549182127f40aa9395
Author: Robin Sheat <robin at catalyst.net.nz>
Date:   Mon Mar 17 18:33:00 2014 +1300

    Bug 11947 - renumber reserves when hold is confirmed
    
    Currently when a reserve is moved to "waiting" status because it's
    acknowledged on checkin, the reserve priorities aren't renumbered. This
    causes things to go a bit haywire in the UI, in particular, some
    reserves can unjustly end up with priority 1 when they shouldn't. It
    also seemed to mess with the logic of who should get it next, but I
    didn't look too closely at that.
    
    This patch forces a renumbering so that all the priorities remain
    copacetic.
    
    Test plan:
    * have a few borrowers, say 4.
    * have a biblio with a single item (you can scale this up, it should
      work just the same.)
    * issue the item to borrower A
    * have borrowers B, C, and D place a hold on the item
    * return the item, acknowledge that it'll be put aside for B.
    * view the holds on the item.
    Without the patch:
    * the hold priorities in the UI end up being "waiting, 2, 1" when they
      should be "waiting, 1, 2".
    * in the database "reserves" table, they're really "0, 2, 3" when they
      should be "0, 1, 2".
    With the patch:
    * the hold priorities in the UI end up being "waiting, 1, 2"
    * in the database, they're "0, 1, 2"
    
    Signed-off-by: Owen Leonard <oleonard at myacpl.org>
    
    Test plan confirms that the problem exists and that the patch corrects
    it.
    
    Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
    Passes all tests and QA script, especially t/db_dependent/Reserves.t.
    Improves priority calculation.
    
    Signed-off-by: Galen Charlton <gmc at esilibrary.com>
    (cherry picked from commit 95056d17b715b74e3f7149d60e12d5a365d70eeb)
    Signed-off-by: Fridolin Somers <fridolin.somers at biblibre.com>

-----------------------------------------------------------------------

Summary of changes:
 C4/Reserves.pm            |    8 +++++---
 t/db_dependent/Reserves.t |   30 +++++++++++++++++++++++++++++-
 2 files changed, 34 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
main Koha release repository


More information about the koha-commits mailing list