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

[Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #7 from Lucas Gass <lucas(a)bywatersolutions.com> --- I would love to see this get back on the roadmap, perhaps for 23.11. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33579] New: Typo: record record
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33579 Bug ID: 33579 Summary: Typo: record record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org $ grep -rn "record record" * koha-tmpl/intranet-tmpl/prog/en/modules/admin/background_jobs.tt:184: '_str': _("Batch bibliographic record record deletion") -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 33303] New: Performance issues/timeouts when using more_subfields_xml in item search
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33303 Bug ID: 33303 Summary: Performance issues/timeouts when using more_subfields_xml in item search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using items from more_subfields_xml in item search there are performance issues, especially on bigger data sets. more_subfields_xml is an XML blob type column in the items table, that will be used when you create additional item fields not mapped to another column in the items table. Not sure if something could be done here, but maybe there is something we could do to optimize processing? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 11300] Add a new authority linker which searches for authority links on a Z39.50 server.
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11300 --- Comment #59 from Phil Ringnalda <phil(a)chetcolibrary.org> --- I wasn't asking for a weird enhancement I just thought of, I was describing the behavior of an authority linker. Order matters, Dogs -- Food and Food -- Dogs are not the same headings. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33816] New: Holds API errors not easily machine-readable
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33816 Bug ID: 33816 Summary: Holds API errors not easily machine-readable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au CC: tomascohen(a)gmail.com At the moment, if you place a hold via the Holds API and there are too many holds for the record, you get the following response: {"error":"Hold cannot be placed. Reason: tooManyHoldsForThisRecord"} That's a message that is meant for a human developer. It's not showable to a human audience, and it's not easily parsed by a machine. It would be good to have a human readable message for troubleshooting, but the core error code should just be "tooManyHoldsForThisRecord", as a machine can take that string and work with it as a code. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15567] Update API to allow multiple holds for the same record
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15567 --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #6) > Surely it would make sense to just take multiple items in as input and then > run it through a loop and record the results. I mean I've created my own API endpoint in a different system which takes data for multiple items and does exactly that, so that 1 API call on that system can place holds for multiple items at the same time. (It's just the backend API call to the Koha that has to be done X times.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15567] Update API to allow multiple holds for the same record
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15567 --- Comment #6 from David Cook <dcook(a)prosentient.com.au> --- Not sure why this would depend on bug 15565... Looks like this patch adds way too much logic into the controller. Surely it would make sense to just take multiple items in as input and then run it through a loop and record the results. If we have the API endpoint, then maybe we can change the UIs to use the API and sidestep even needing 15565 as it stands -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14695] Add ability to place multiple item holds on a given record per patron
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 --- Comment #244 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #243) > (In reply to David Cook from comment #241) > > Was this feature reverted? I've never actually seen it operational in Koha, > > which is why bug 15565 exists in its present all-encompassing state? > > It's possible in staff, but you need to allow multiple holds on one record > in circulation rules. OPAC implementation is pending. I think maybe I've always misunderstood this one. I thought it was supposed to allow you to place multiple item level holds at the same time. "At the same time" meaning during the "placing" of the hold rather than the "having" of the hold. And that's why we still need bug 15565 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26598] New: Display guarantee's fines on guarantor's details page
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26598 Bug ID: 26598 Summary: Display guarantee's fines on guarantor's details page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: maryse.simard(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Add a new tab to the details page of a patron to show, in a table, the fines of the patron's guarantees. A warning appears in the "Guarantees" section of the patron to make it obvious that fines exists. Note: This was first introduced as part of Bug 12446, but ultimately was split into it's own bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 33814] New: HOLD notices for email and sms do not enqueue even if enabled
by bugzilla-daemon＠bugs.koha-community.org 23 May '23

23 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33814 Bug ID: 33814 Summary: HOLD notices for email and sms do not enqueue even if enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org I'm marking this Major because of the impact on customer service, but if Normal would be more appropriate feel free to adjust. I'm seeing this bug in 22.11.04 and in master: when a hold is set to Waiting, only the print notice for "hold waiting" is enqueued on the patron's account, even if the patron has email and/or SMS notices for waiting holds enabled on their account. Unless this is a display error in the patron notices tab (not sure how likely that is or how to test for that in a test environment), this would mean that the patron has no way of being notified when their hold is ready for pickup. To reproduce: 1. Edit a patron's Messaging Preferences to enable email/SMS notices for "Hold Filled" 2. Place a hold for that patron 3. Check in an item to fill the hold 4. Go to the patron's account and click the Notices tab Note that an enqueued print notice appears in the patron's notices table for the available hold, but there is no email or SMS notice listed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1