[koha-commits] main Koha release repository branch 3.8.x updated. v3.08.01-10-gd4f21ef

[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.8.x has been updated
       via  d4f21ef40c77096269b8a2c51c6fdd3814361f47 (commit)
      from  7a11e547e51e3a5b3b24e1df3b561758a6a3d0b1 (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 d4f21ef40c77096269b8a2c51c6fdd3814361f47
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date:   Wed Feb 8 12:16:20 2012 -0500

    Bug 7112 - Having two prices in 020$c causes basket creation to fail from staged marc import
    
    The root problem here is that the price is being pulled from the MARC record
    and is then run through Number::Format::unformat_number. This routine is
    really being misused, and should only be used to reverse the effects of
    Number::Format on a number string. We are apparently using it to strip
    out currency characters and the like.
    
    Number::Format::unformat_number will choke if there is more than one period (.)
    in the price field. MARC standards do not limit this field to a single period,
    so unless there is only one period, we should skip number unformatting.
    Examples of that break unformat_number include '18.95 (U.S.)', and
    '$5.99 ($7.75 CAN)', both of which are perfectly valid.
    
    This commit adds the function MungeMarcPrice that will better handle
    find a real price value in a given price field. It does a very good
    job at finding a price in any currency format, and attempts to find
    a price in whichever currency is active before falling back to
    the first valid price it can find.
    
    The variable $price may fail to have an actual price, in which case
    the price then defaults to '0.00', which would be rarely if ever the
    correct price. To combat this, I have added highlighting to any
    price in the Order Details table that begins with 0 ( i.e. '0.00' ).
    
    Also, fixed the incomplete table footer, adding a new td with a
    span of 3 to fill in the nonexistant cells.
    
    Signed-off-by: Jared Camins-Esakov <jcamins at cpbibliography.com>
    Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>

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

Summary of changes:
 C4/Biblio.pm                                       |   45 ++++++++++++++++++++
 acqui/addorderiso2709.pl                           |   10 +---
 .../intranet-tmpl/prog/en/modules/acqui/basket.tt  |    9 ++--
 3 files changed, 53 insertions(+), 11 deletions(-)


hooks/post-receive
-- 
main Koha release repository