[koha-commits] main Koha release repository branch master updated. v19.05.00-1123-g2a3429b

[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, master has been updated
       via  2a3429b65d47163a98a47f98458ce5c7262421a5 (commit)
       via  44c44b28d4ab0fc7daf9c76c643cba6e6a204634 (commit)
       via  8c94bdcd16d28d966b6b39798b212d9fcf7605e7 (commit)
       via  fb083813a8237691f0b9d419d826fdea58096cd4 (commit)
      from  fe5c65c5cd1a797324a8c3c28d66e691a6d68b1a (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 2a3429b65d47163a98a47f98458ce5c7262421a5
Author: caroline <caroline at inlibro.com>
Date:   Mon Oct 21 10:25:55 2019 -0400

    Bug 23853: Typo in authorised_values.tt
    
    This patch corrects the Bsort1 typo in authorised_values.tt and changes the Bsort2 description to match Bsort1's.
    
    To test:
    1- Go to Administration > Authorised values
    2- Make sure descriptions for Bsort1 and Bsort2 match their category and are the same (except for 1 and 2)
    
    Signed-off-by: Séverine QUEUNE <severine.queune at bulac.fr>
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

commit 44c44b28d4ab0fc7daf9c76c643cba6e6a204634
Author: Nick <nick at bywatersolutions.com>
Date:   Sat Sep 21 11:33:47 2019 +0000

    Bug 23663: Only process itemtype summary if using non-xslt opac results
    
    To test:
    1 - Set OpacXSLTResultsDisplay to "" to use non-xslt view
    2 - In Administration->Itemtypes define a summary for an itemtype:
        This is the summary for [245a]
    3 - Perform a search on the opac that will return results with this itemtype
    4 - Note "This is the summary" appears in results with the title
    5 - Set OPACXSLTResultsDisplay to 'default'
    6 - Refresh your search results, note the summary disappears
    7 - Try search in other places and note that summary never appears
    8 - Apply patch
    9 - Repeat 1-7 and note nothing changed
    
    Signed-off-by: Katrin Fischer <katrin.fischer.83 at web.de>
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

commit 8c94bdcd16d28d966b6b39798b212d9fcf7605e7
Author: Fridolin Somers <fridolin.somers at biblibre.com>
Date:   Thu Jun 8 16:22:55 2017 +0200

    Bug 18757: Problem when importing only items in MARC records
    
    When importing records with Stage MARC records for import, one can use matching rules to only import items into existing records.
    Those imported items are stored as XML to be staged.
    
    The bug is that when MARC Flavour is UNIMARC the XML serialization fails because its is looking in field 100$a which does not exist.
    You see in logs the error : Unsupported UNIMARC character encoding [] for XML output for UNIMARC; 100$a
    
    This patch adds the format "USMARC" to XML serialization, like in C4::Items::_get_unlinked_subfields_xml
    
    Test plan :
    - On a UNIMARC database
    - Define a maching rule on title 200$a
    - Select a record with items
    - Export it using : Save as > MARC (Unicode/UTF-8)
    - Delete all items
    - Go to Tools > Stage MARC records for import
    - Upload exported file
    - Select title matching rule
    - Select "Ingore incoming record" in "Action if matching record found :"
    - Select Yes and "Always add items" in "Check for embedded item record data?"
    - Click Stage for import
    => Without patch you get the error
    => With patch the import is staged
    - Import into the catalog and check item is well recreated
    
    Signed-off-by: Amandine Zocca <azocca at ville-montauban.fr>
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

commit fb083813a8237691f0b9d419d826fdea58096cd4
Author: Fridolin Somers <fridolin.somers at biblibre.com>
Date:   Thu Sep 19 16:55:51 2019 +0200

    Bug 23630: Do not remove field 999 in Elasticsearch indexing
    
    Elasticsearch indexing uses 999$c to store record id by deleting the all field first !
    So you can not store anything in field 999, even in UNIMARC and even in authorities records.
    
    Looks like it is quick fix code added to start Elasticsearch use.
    
    This behavior is disturbing and very strange for UNIMARC flavour.
    
    This patch corrects by defining record ids mandatory in Koha::SearchEngine::Elasticsearch::Indexer::update_index().
    This ids array is actually always given (except in UT).
    I think it is useless to allow adding a record without its id.
    
    Test plan :
    1) Use Elasticsearch as SearchEngine
    2) Create a subfield 999$z in default framework
    3) Create a record with default framework
    4) Enter a random string (never used in catalog) like "tototata" in 999$z
    5) In Search engine configuration, define search field "subject" for 999$z
    6) Rebuild record : misc/search_tools/rebuild_elasticsearch.pl -b -bn <biblionumber> -v
    7) Search for the random string => You get a result
    8) Optionnaly look at records in ES : <es server>:9200/<es index name>/data/<biblionumber>
    
    Signed-off-by: Nick Clemens <nick at bywatersolutions.com>
    Signed-off-by: Martin Renvoize <martin.renvoize at ptfs-europe.com>

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

Summary of changes:
 C4/ImportBatch.pm                                  |    2 +-
 C4/Search.pm                                       |    5 ++-
 Koha/SearchEngine/Elasticsearch.pm                 |    5 +--
 Koha/SearchEngine/Elasticsearch/Indexer.pm         |   39 ++------------------
 .../prog/en/modules/admin/authorised_values.tt     |    4 +-
 .../Koha/SearchEngine/Elasticsearch/Indexer.t      |    2 +-
 6 files changed, 12 insertions(+), 45 deletions(-)


hooks/post-receive
-- 
main Koha release repository