[koha-commits] main Koha release repository branch master updated. v3.16.00-1083-g866017e

Mon Nov 17 01:18:29 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  866017e1523ec430d4ec37fc92a02edb86c106e5 (commit)
       via  474735017379277b5f613b43686049ff955e152f (commit)
       via  94687cf57a67515204ace0949a3e4d3e75ca41b1 (commit)
       via  17e6a8b6527acb063a877db97f88e161c35885ce (commit)
      from  e3d1e527e7cf23c20db8ed35c8de678d8f8a9d92 (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 866017e1523ec430d4ec37fc92a02edb86c106e5
Author: Rafal Kopaczka <rkk0 at poczta.onet.pl>
Date:   Fri Nov 14 14:06:22 2014 +0100

    Bug 13254 - Delete record don't wait for confirmation

    In some cases (eg. when Staf Client Search is active), when user choose
    Edit->Delete record on record tool bar, browser don't wait for
    confirmation and goes immediately to delete record.

    To reproduce:
    1. Search for some biblio records and choose one without items attached.
    2. Note that there, must be "Return to search results" box on left side,
    bug works in that case, when in normal view everything work fine.
    3. Click Edit->Delete record, watch that confirmation box shows, but
    don't wait for OK and runs immediately. If you are fast enough to
    click OK, then you get error as below, because record was deleted
    earlier.

    To test:
    1. Apply patch.
    2. Follow reproduce steps.
    3. Check if waits for confirmation in all cases.
    4. Check if deletes record after confirm.

    Followed test plan. Patch behaves as expected.
    Signed-off-by: Marc Véron <veron at veron.ch>

    Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
    Confirmed the problem and that the patch fixes it.
    Good catch!

    Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>

commit 474735017379277b5f613b43686049ff955e152f
Author: Katrin Fischer <Katrin.Fischer.83 at web.de>
Date:   Sun Nov 9 22:25:32 2014 +0100

    Bug 10878: Correct Display856uAsImage pref description

    Removes note about Display856uAsImage not working on
    the OPAC result page.

    To test:
    - catalog a record with 856$u = URL to an image, $q = img
    - turn on the system preference Display856uAsImage
    - check that the pref description makes sense and is correct
      - the warning about the pref not working on result pages
        has been removed
    - make sure your record has been reindexed by Zebra
    - verifiy the image indeed displays on the result page
      in the bootstrap catalog.

    Note: The height=100 doesn't work in the Boostrap catalog,
    so the images display in their original size. Will file
    a separate bug for this.

    Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>
    Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>

commit 94687cf57a67515204ace0949a3e4d3e75ca41b1
Author: Owen Leonard <oleonard at myacpl.org>
Date:   Fri Nov 14 10:49:18 2014 -0500

    Bug 13258 - Clicking the "show checkouts" button should return focus to the barcode field

    This patch udpates the checkouts JavaScript so that clicking the "show
    checkouts" button or the "always show checkouts" checkbox returns focus
    to the barcode field. This improves the checkout workflow by eliminating
    a mouse click.

    To test, apply the patch and clear your browser cache. Check out to a
    patron and confirm that focus is returned to the barcode field after
    clicking the "show checkouts" button and the "always show checkouts"
    checkbox.

    Patch behaves as expected.
    Signed-off-by: Marc Véron <veron at veron.ch>

    Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
    Works as described, no problems found.

    Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>

commit 17e6a8b6527acb063a877db97f88e161c35885ce
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date:   Thu Nov 13 12:03:42 2014 -0500

    Bug 12778 - Regression: Item lost status doesn't show in list of checkouts

    When using the longoverdue script it's possible that items marked lost
    remain on the patron account. I think it's important for staff to see
    that some items are marked lost - currently the list of checkouts
    doesn't show any sign of the lost status.

    Test Plan:
    1) Find a patron with a checked out lost item
    2) Note the lost status is not displayed in the checkouts table
    3) Apply this patch
    4) Refresh the page, note the lost status now displays
    5) Repeat this test plan for a damaged item

    Signed-off-by: Owen Leonard <oleonard at myacpl.org>
    Tested successfully with damaged and multiple lost values.

    Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
    Works as described, no problems found.

    Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>

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

Summary of changes:
 .../intranet-tmpl/prog/en/includes/cat-toolbar.inc |    2 +-
 koha-tmpl/intranet-tmpl/prog/en/js/checkouts.js    |   20 +++++++++++++++++---
 .../prog/en/modules/admin/preferences/opac.pref    |   10 +++++-----
 .../en/modules/admin/preferences/staff_client.pref |   10 +++++-----
 svc/checkouts                                      |    9 +++++++--
 5 files changed, 35 insertions(+), 16 deletions(-)

hooks/post-receive
-- 
main Koha release repository