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

[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 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

[Bug 7789] New: Add translations of item type and authorized value descriptions
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '15

24 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7789 Priority: P5 - low Change sponsored?: --- Bug ID: 7789 Assignee: frederic(a)tamil.fr Summary: Add translations of item type and authorized value descriptions QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: NEW Version: master Component: I18N/L10N Product: Koha Created attachment 8471 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8471&action=edit Mockup of a possible implementation for Item Types Since descriptions of item types and authorized values are stored in the database, there is no way to translate them. This creates a problem if the descriptions in the database are in one language but your user has switched to another. I propose that we add a language column to the itemtypes and authorised_values tables. For existing installations the existing data would remain with an empty "language" value, and this option would be displayed by default. If a library adds a set of language-specific translations that set will be displayed when that language is chosen. I think the entry form would not require extensive updating, but the display of existing values in Administration might. I'm thinking that each language's values might be displayed in a separate tab. See the attached mockup. The tabs could be displayed based on enabled languages. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 12157] New: Batch delete for serial holdings
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12157 Bug ID: 12157 Summary: Batch delete for serial holdings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Request by a library: Currently we have to delete serial holdings one by one, it would be nice to be able to delete several (or many) at one time with a batch delete function for serial holdings. This would not necessarily have to delete the associated holding item, only the serial record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13414] New: Enable right truncation with search by relevance
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13414 Bug ID: 13414 Summary: Enable right truncation with search by relevance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 34199 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=34199&action=edit Enable right truncation with search by relevance This patch slightly modifies build_weighted_query function (Search.pm) that defines the ranking levels for a search by relevance in order to make right truncation possible when QueryWeightFields syspref is activated (even ranked with little weight) it modifies the type of this syspref from boolean to choice in order to add this possiblity as a third option : Search by relevance with right truncation. Default remains Search by relevance (without truncation). -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 9768] New: Problem with grace period calculation and fine intervals >1
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9768 Bug ID: 9768 Summary: Problem with grace period calculation and fine intervals >1 Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With a fine interval > 1 there is currently no way to avoid a effective grace period. Fines can not start the day after the due date. Configuration: With grace period = 1 fine interval 5 (= weekly, the library is closed Sunday and Saturday) Result: The first fine ist set 7 days after the item was due. Monday, checkout Tuesday, item due Wednesday Thursday Friday Saturday, holiday Sunday, holiday Monday, Tuesday, first fine Grace period for fine intervals > 1 should describe the days between the due date and the day the first fine is set. CalcFines() in Overdues.pm: 266 my $days_minus_grace = $daystocharge - $data->{'firstremind'}; 267 if ($data->{'chargeperiod'} > 0 && $days_minus_grace > 0 ) { 268 $amount = int($daystocharge / $data->{'chargeperiod'}) * $data->{'fine'}; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 13590] New: Add ability to charge fines at start of charge period
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13590 Bug ID: 13590 Summary: Add ability to charge fines at start of charge period Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Right now, Koha only charges fines at the end of a given charge period. For example, let us assume a circulation rule has a charge period of one week ( 7 days ) and a fine of $5. This means that an item can be overdue for 6 days without accruing a fine. Koha should allow circulation rules to be configured to place the charge at the start of the end of the charge period so the library can decide when the fine should accrue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 14293] New: Error in the calculation of the suspension of users per day
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14293 Bug ID: 14293 Summary: Error in the calculation of the suspension of users per day Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: felipe.gomez3(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the system is miscalculating the day suspension when a loan is made hours. Add 24 days for each day in fines. The problem occurs when changed in version 3.16.X my $deltadays = $calendar->days_between( $dt_due, $dt_today ); by my $chargeable_units = C4::Overdues::get_chargeable_units($unit, $dt_due, $dt_today, $branchcode); In version 3.18.X, 3.20.X And the line is not necessary: $finedays = $finedays * 24 if ( $unit eq 'hours' ); Which is generating an error in the calculation of the suspension days ______________________________________ Spanish Error en el calculo de la suspensión de usuarios por Días Actualmente el sistema se encuentra calculando mal los días de suspención cuando se hace un préstamo por Horas. Agrega 24 Días por cada día de multa. El problema aparece Cuando cambiaron en la versión 3.16.X my $deltadays = $calendar->days_between( $dt_due, $dt_today ); Por my $chargeable_units = C4::Overdues::get_chargeable_units($unit, $dt_due, $dt_today, $branchcode); En la versión 3.18.X, 3.20.X Ya no se hace necesario la línea: $finedays = $finedays * 24 if ( $unit eq 'hours' ); La cual está generando un error en el cálculo de la suspensión por días. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 12194] New: Some fonts don't work on printing label
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12194 Bug ID: 12194 Summary: Some fonts don't work on printing label Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label printing Assignee: cnighswonger(a)foundations.edu Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CO, CBO, HO and HBO fonts don't work If you select one of these font, you got ERROR in koha-conf.xml -- missing <font type="HBOO">/path/to/font.ttf</font> at /home/koha/src/C4/Creators/PDF.pm line 123ERROR in koha-conf.xml -- missing <font type="HBOO">/path/to/font.ttf</font> at /home/koha/src/C4/Creators/PDF.pm line 123 in Koha logs. see bug 8375 comment 83 and following. -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 13971] New: Adjusted locations in koha-rebuild-zebra for gitified instance
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13971 Bug ID: 13971 Summary: Adjusted locations in koha-rebuild-zebra for gitified instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10