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

[Bug 14376] New: Allow the librarian to choose a patron when entering a purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '15

25 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14376 Bug ID: 14376 Summary: Allow the librarian to choose a patron when entering a purchase suggestion Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[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 14653] New: Acq planning filter and export always use default active period
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '15

24 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14653 Bug ID: 14653 Summary: Acq planning filter and export always use default active period Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In Acq planning /cgi-bin/koha/admin/aqplan.pl, left side filter and export forms have no parameter budget_period_id nor authcat, so the use the default active period. As said in code : # IF PERIOD_ID IS DEFINED, GET THE PERIOD - ELSE GET THE ACTIVE PERIOD BY DEFAULT my $period = GetBudgetPeriod($budget_period_id); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 14642] New: Add logging of hold modifications
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14642 Bug ID: 14642 Summary: Add logging of hold modifications Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle.m.hall(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I think it's high time we added a HoldsLog system preference to log creation, updating, and filling of holds. I would say the following is needed: 1) Hold creation ( staff/opac, bib, item, date, priority ) 2) All hold modifications ( changing of priorities except for reflowing priorities, trapping an item to a hold, deleting a hold, etc ) 3) Hold fulfillment -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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 14528] New: Viewing lists fails silently when not having correct permisison
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '15

23 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14528 Bug ID: 14528 Summary: Viewing lists fails silently when not having correct permisison Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: koha(a)jsense.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Whilst testing the list permissions I found a problem. I have an account with staff client access and I went to the Lists module. You immediately get "Processing..." whilst an Ajax request takes place but then nothing else happens. I can debug to see that the search request failed to to not having permission. My primary concern is that I don't think any Ajax service call should fail silently like this - the user need to know it has failed. In this case the permission needed was "borrowers" - see /svc/virtualshelves/search. That doesn't make any sense to me - why would I need to have permission to "Add or modify patrons" when I just want to see Lists? Lastly, there may be some connection to issue 6960 but fixing that would only hide the primary problem described above. To reproduce: 1. Set up a user without "borrowers" permission 2. Go to /cgi-bin/koha/virtualshelves/shelves.pl 3. Note that it says "Processing..." and never completes. -- You are receiving this mail because: You are watching all bug changes.

1 12

[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