September 2015 - Koha-bugs - lists.koha-community.org

[Bug 11780] New: Need to prevent specific fields from being overwritten with z39.50 import
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11780 Bug ID: 11780 Summary: Need to prevent specific fields from being overwritten with z39.50 import Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In our previous LMS we could associate specific marc fields as "local use" in the configuration. If a marc record was overwritten with another via z39.50 these local use files remained in the new record. (if it was in a field that also contained data in the incoming record, then a 2nd instance for that field was created - e.g. multiple 500 notes, etc e.g. we need to keep our own 001 control numbers as Analytics links from other records get broken if this is replaced with the 001 of a new record say from LC or NLM. At the moment I have to note the existing 001 & put that value in again after replacing the record. There are also local notes fields etc that we would want to keep. It would be useful if this setting is also framework specific. (e.g. to keep certain fields for serials but not for monographs etc) -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 14622] New: Add fr-CA data folder in the web installer
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14622 Bug ID: 14622 Summary: Add fr-CA data folder in the web installer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: francois.charbonnier(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com New data in French Canadian for the web installer. It contains translations of every files from the English folder. The marcflavour directory is a bit different. 1. MARC21 is the only marc flavour translated. 2. marc21_framework_DEFAULT.sql contains : - the default framework - the acquisition framework - the fast-add framework - the RDA framework 3. In addition, there is a simplified framework in the optional folder. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 5560] New: pagination option for lists
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5560 Summary: pagination option for lists Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Virtual Shelves AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Right now lists show 20 items per page and this is not changeable. I would like to see an option at list creation that lets me say how many items I want to show per page. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 8

[Bug 12759] New: Add ability to pass list contents to batch item modification/deletion tools
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12759 Bug ID: 12759 Summary: Add ability to pass list contents to batch item modification/deletion tools Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be a great timesaver if the records associated with a particular list can be passed into the Batch item modification and batch item deletion tools. At the moment I have to run a report to extract the item barcode numbers from the list then open the resulting spreadsheet and copy & paste these into the batch modification tool. Ideally the batch modification/deletion tools need another input option to choose a particular list (that you can access), or alternatively have a new option in the list view screen to pass selected records to batch modification/deletion. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 14824] New: Fix sorting of Norwegian vowels
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14824 Bug ID: 14824 Summary: Fix sorting of Norwegian vowels Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Currently, if you sort bibliographic search results by title, the Norwegian wovels ÆØÅ will not be sorted correctly. Specifically, with a result list containing 4 results, I was getting this for an A-Z (or A-Å) sort: Å... Æ... H... Ø... Which is just about as incorrect as it gets. As documented here: http://www.indexdata.com/zebra/doc/character-map-files.html sorting in Zebra is governed by the "lowercase" and "uppercase" setting in sort-string-utf.chr. That page suggests this for scandinavian languages: lowercase {0-9}{a-y}üzæäøöå uppercase {0-9}{A-Y}ÜZÆÄØÖÅ But with that config I got warnings during rebuild zebra: 10:05:00-15/09 zebraidx(26924) [warn] duplicate entry for charmap from 'ä' 10:05:00-15/09 zebraidx(26924) [warn] duplicate entry for charmap from 'Ä' 10:05:00-15/09 zebraidx(26924) [warn] duplicate entry for charmap from 'ö' 10:05:00-15/09 zebraidx(26924) [warn] duplicate entry for charmap from 'Ö' 10:05:00-15/09 zebraidx(26924) [warn] duplicate entry for charmap from 'ü' 10:05:00-15/09 zebraidx(26924) [warn] duplicate entry for charmap from 'Ü' I assume this is because these characters are already mapped to other chars. So I will propose a patch that uses this simplified setting: lowercase {0-9}{a-z}æøå uppercase {0-9}{A-Z}ÆØÅ -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 12904] New: Force browser to load new javascript files after upgrade
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12904 Bug ID: 12904 Summary: Force browser to load new javascript files after upgrade Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org A common issue with Koha seems to be that the web browsers continue to use cached js files after an upgrade. If we append the version as a parameter, we can force the browser to update the javascript files. -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 11626] New: Cannot receive serial issues after subscription expiry date
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11626 Bug ID: 11626 Summary: Cannot receive serial issues after subscription expiry date Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Some of our serials subscriptions were not renewed after 31/12/2013 but I cannot receive any of the outstanding 2013 issues unless I renew the subscription record (a couple of publishers are about 3 months late with their printing/postage schedules compared to the subscription/cover dates). For a couple of these titles we do not have a 2014 subscription so it is not appropriate to renew the subscription record. We should still be able to receive late issues after the subscription expiry date (the date published for these issues would in most cases be on or before the expiry date) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 13665] New: Retrieve facets from zebra is slow
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13665 Bug ID: 13665 Summary: Retrieve facets from zebra is slow Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 11232 With a 1 million biblio records installation (MARC21 + DOM), a search is very slow if facets are retrieved from zebra. Debugging, I found where the processing time is spent: In C4::Search::_get_facet_from_result_set, the line my $facet = $rs->record( 0 )->raw; can spent up to 3 seconds! Actually it's the ->record call, not the ->raw. In ZOOM->record, the time is spent in my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which); I stopped the track game at this point. So for instance, with a facet holdingbranch, (FacetMaxCount set to 20) the element zebra::facet::su-to:0:20" is set, $rs->size returns 962076, and the total execution time for _get_facet_from_result_set (only for this facet!) is 3.2sec. If I set FacetMaxCount to 1, I got: 0.3 sec, for 10: 1.67. So quite linear. Lets compare with yaz-client: Z> open unix:/home/koha/var/run/zebradb/bibliosocket Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.009150 Z> base biblios Z> format xml Z> elem zebra::facet::holdingbranch:0:20 Z> f d Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 809470, setno 1 SearchResult-1: term=d cnt=809470 records returned: 0 Elapsed: 0.078905 Z> s 1+1 Sent presentRequest (1+1). Records: 1 Record type: XML <record xmlns="http://www.indexdata.com/zebra/"> <facet type="0" index="holdingbranch"> <term coccur="941" occur="103144">br1</term> [...] </facet> </record> nextResultSetPosition = 2 Elapsed: 1.393694 To compare with the old facet method, I calculated the time spend in C4::Search::GetFacets (for 20 facets): >From zebra (new): 9.3sec >From Records (old): 0.16sec (with maxRecordsForFacets = 20) >From Records (old): 1.85sec (with maxRecordsForFacets = 100) >From Records (old): 15.1sec (with maxRecordsForFacets = 1000) Note that the machine is a test machine (VE) and is quite slow. Firebug tells me that with the new method (20 facets), the total load page is ~30sec, with the old method (20 facets calculated from 20 records) is 8-9sec -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 14584] New: Encoding broken with system preferences
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14584 Bug ID: 14584 Summary: Encoding broken with system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This bug is related to #12411 and #11944, since then pushed to master. Whatever we enter with accents in NoLoginInstructions is displayed as gibberish because it ends up being encoded TWICE. It was not doing that before. My solution is to modify Koha::Template::Plugin::Koha::Preference. It might be naive and missing all the changes done in aforementionned bugs, but this does fix my immediate issue in 3.20 and master. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 12785] New: OPAC normal view displays unwanted ISBD punctuation
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '15

26 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12785 Bug ID: 12785 Summary: OPAC normal view displays unwanted ISBD punctuation Change sponsored?: --- Product: Koha Version: 3.14 Hardware: PC OS: Windows Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: pesenti411(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 30978 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30978&action=edit Display of the punctuation in Opac normal view When displaying results in Normal view, the publisher data includes the punctuation. Could it be an error in cataloguing, or should I configure the OPAC differently? I use an image of Koha 3.14 in VIrtual Box on Windows 8.1 -- You are receiving this mail because: You are watching all bug changes.

1 4