[koha-commits] main Koha release repository branch 3.18.x updated. v3.18.10-7-g6eb7866

[Git repo owner]

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.18.x has been updated
       via  6eb786648fc01715841b73044ec1cf64c3aa147c (commit)
       via  bb1ab847299677ca798ca07691b4bf965b1521a8 (commit)
       via  a15a88fa8276b77f8960173dea025f8d9c049aff (commit)
      from  27a0e22440d348d29a5dac20215c9a2a9cdcd808 (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 6eb786648fc01715841b73044ec1cf64c3aa147c
Author: Aleisha <aleishaamohia at hotmail.com>
Date:   Mon Aug 3 02:23:29 2015 +0000

    Bug 14634: Warns when placing hold on record with no items
    
    To test:
    
    1) Create a new record in Cataloguing
    2) When done, instead of adding an item to the record, click on the Holds tab in the left nav
    3) Notice warns
    4) Apply patch and refresh page
    5) Click on Holds tab again
    6) Notice warns are gone and page still works
    
    Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
    Warns disappear; note that the display of the error message is still ugly.
    
    Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
    Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
    Signed-off-by: Liz Rea <wizzyrea at gmail.com>

commit bb1ab847299677ca798ca07691b4bf965b1521a8
Author: Benjamin Rokseth <benjamin.rokseth at kul.oslo.kommune.no>
Date:   Mon Jun 8 11:12:03 2015 +0200

    Bug 14361: koha-restart-zebra fails and probably breaks upgrade
    
    This patch fixes the koha-restart-zebra and koha-stop-zebra scripts
    by adding pidfiles folder to the test is_zebra_running.
    It also adds pidfiles to the test is_indexer_running so that
    koha-rebuild-zebra will work properly.
    
    Test plan:
    1) check if zebrasrv is running, get pid of zebrasrv
       ps ax | grep zebrasrv
    2) In my case, there was also a warning on the about.pl page on a fresh
       install: Error message from Zebra: 1011 (bad credentials)
    3) try to restart zebra
       koha-restart-zebra instancename
       You will get a msg :
       Zebra does not appear to have been running for instancename
       Starting Zebra server for instancename
    4) check again if zebrasrv is running
        ps ax | grep zebrasrv
       and see that pid has not changed, thus it is not restarted
    5) Apply patch
    6) repeat 4) and watch now how pid has changed
       If there was a warning on about.pl it should now be gone
    
    Signed-off-by: Mason James <mtj at kohaaloha.com>
    Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
    Good catch Benjamin! It works as expected with the patch.
    
    Signed-off-by: Liz Rea <wizzyrea at gmail.com>

commit a15a88fa8276b77f8960173dea025f8d9c049aff
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date:   Fri Aug 22 13:29:28 2014 -0400

    Bug 12632: Hold limits ignored for record level holds with item level itemtypes
    
    The crux of the issue is that if you are using item level itemtypes, but
    are allowing biblio levels holds, those holds do not have items.
    
    So, in CanItemBeReserved, when Koha counts the number of holds to
    compare against the given rule, it will always give 0 ( except of course
    for found holds, and the occasional item-level hold ).
    
    So the query is saying "link each of these reserves to the reserved
    item, and count the number of reserves this patron where the itemtype is
    DVD". However, since these are all record level reserves, there are no
    items to link to, and so when it looks for all reserves this and item
    whose itemtype is DVD, it finds zero reserves!
    
    This patch solves the problem by looking first at the item level
    itemtype, and if it does not exist, then it looks at the record
    level itemtype. For installations using record level itemtypes, the
    behavior remains unchanged.
    
    Test plan:
    1) Enable item level itemtypes
    2) Create two records with one item each of a given itemtype
    3) Create a single issuing rule and limit the holds allowed for that
       itemtype to 1
    4) Place a record level hold on your first record
    5) Attempt to place a record level hold for the same patron on your
       second record. You should not be able to but you can!
    6) Apply this patch
    7) Repeat step 5, note you can no longer place the hold!
    
    Signed-off-by: Paola Rossi <paola.rossi at cineca.it>
    
    Signed-off-by: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
    Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
    Signed-off-by: Liz Rea <wizzyrea at gmail.com>

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

Summary of changes:
 C4/Reserves.pm                   |   10 ++++++++--
 debian/scripts/koha-functions.sh |    2 ++
 reserve/request.pl               |    1 +
 3 files changed, 11 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
main Koha release repository