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

[Bug 26225] New: Move translatable strings out of audio_alerts.tt and into audio_alerts.js
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '20

27 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26225 Bug ID: 26225 Summary: Move translatable strings out of audio_alerts.tt and into audio_alerts.js Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr, testopia(a)bugs.koha-community.org Depends on: 21156 Strings defined for translation in admin/audio_alerts.tt can now be wrapped in the new translation function and put in audio_alerts.js. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 26556] New: Cities autocomplete broken in patron edition
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '20

27 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26556 Bug ID: 26556 Summary: Cities autocomplete broken in patron edition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Selecting "main address" city or "alternate address" city does not trigger the automatic population of values to the city, state, and zip fields anymore. It woks for "alternate contact". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 26249] New: keep_text class not set inconsistently in cat-search.inc
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '20

27 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26249 Bug ID: 26249 Summary: keep_text class not set inconsistently in cat-search.inc Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In cat-search.inc, the keep_text class should be set on the A elements but the "Search the catalog" is set on the LI element. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 25624] New: Update patrons category script should allow finding null and not null and wildcards
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '20

27 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25624 Bug ID: 25624 Summary: Update patrons category script should allow finding null and not null and wildcards Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The script does not allow to find empty fields or use wildcards It would be helpful to find patrons where a field has been set, or a field not matching, or similar fields -- You are receiving this mail because: You are watching all bug changes.

1 50

[Bug 26424] New: Better performance of svc/checkouts
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '20

27 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26424 Bug ID: 26424 Summary: Better performance of svc/checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Ajax script svc/checkouts display checkouts of a patron. For each item, it fetches a Koha::ItemType object and a Koha::AuthorisedValues object for location,ccode,lost and damaged. For performance on huge number of checkouts : Item types should be fetch once before the loop. authorised values should call Koha::AuthorisedValues->get_description_by_koha_field because it uses a cache. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 18958] New: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958 Bug ID: 18958 Summary: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Imagine you have a record with 3 items, each item is held by LibraryA, LibraryB and LibraryC respectively. Now, a patron places to record level holds for pickup at LibraryD. When any of the items are checked in, that item is trapped to fill the first hold, but a side affect is that the next open hold because item level for the item that was just checked in! This is clearly incorrect and prevents the patron from placing more record level holds on the record. To reproduce: 1. Create and use a patron that can place multiple record level holds per record 2. Create a record with X items, each at a different library 3. Place X 'Next available' holds on the record for the patron using the 'Holds to place' box 4. Check in LibraryA's copy as LibraryA and confirm the hold 5. Revisit request.pl for the record, notice the next hold in line is now item-specific 6. Attempt to place another hold for your patron, notice that it requires an item-specific hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 119

[Bug 23212] New: Patron request modifications enhancement
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23212 Bug ID: 23212 Summary: Patron request modifications enhancement Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Currently patron request modifications are an all or none request. Sometimes requests are entered with mistakes. Sometimes patrons are requesting some changes that are questionable, like a complete name change, or removing a birth date. I would like to suggest that each line of request have an approve, deny, or follow-up radio box. If follow-up is chosen, staff have the ability to add a question, and the question is posed to the patron when they log in to the OPAC. Maybe an e-mail notification of the question, if they have e-mail. Once they answer that question, that particular line request is submitted again with the staff question and patron answer. I would also like to suggest that the new value be editable, so if staff need to format something, or fix an obvious mistake, they can. Right now, if we see something like this, we have to click on the patron link to open the account, accept the changes, refresh the patron page, and fix the mistake. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 26452] New: overdue_notices causes "uninitialized value in string"
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26452 Bug ID: 26452 Summary: overdue_notices causes "uninitialized value in string" Change sponsored?: --- Product: Koha Version: 20.05 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: wyneken(a)physik.uni-freiburg.de QA Contact: testopia(a)bugs.koha-community.org I just updated my Koha from 17.05 to 20.05 when I upgraded the server from Debian Stretch to Debian Buster. Now when I execute: koha-foreach --chdir --enabled --email /usr/share/koha/bin/cronjobs/overdue_notices.pl -t I get the following error/warning: Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Overdues.pm line 663. Can anybody tell me what this means? Is it a big problem? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 22834] New: Add a method for plugins to return the absolute path for bundled files
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22834 Bug ID: 22834 Summary: Add a method for plugins to return the absolute path for bundled files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Plugins::Base inherits from Module::Bundled::Files, which is handy to pack assets together and have a simple way to calculate the asset's path. It would help developing new features to have a way to retrieve the absolute path. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 23796] New: Convert OpacCustomSearch system preference to news block
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '20

24 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23796 Bug ID: 23796 Summary: Convert OpacCustomSearch system preference to news block Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 22318 Building on 22318, the OpacCustomSearch system preference should be converted to a Koha news block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22318 [Bug 22318] Extend Koha news feature to include other content areas -- You are receiving this mail because: You are watching all bug changes.

1 20