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

[Bug 20454] New: Suspend Holds if patron wouldn't be able to check items out
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20454 Bug ID: 20454 Summary: Suspend Holds if patron wouldn't be able to check items out 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a person can't check out an item due to hitting the fine limit, it would be great if the holds could be suspended automatically so it wasn't filled until the account was cleared off. This would be a good system preference so systems that didn't want to use it wouldn't be forced into it. Currently in our system patrons can't check out if they have more than $5 in fines. Sometimes they place a hold, rack up fines, and can't check out the book when it comes in for them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 33573] New: Holds cancellation for waiting holds via the API don't generate a cancellation request
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33573 Bug ID: 33573 Summary: Holds cancellation for waiting holds via the API don't generate a cancellation request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com DELETE request to /api/v1/holds/{holdkey} simply cancels a waiting hold if that is allowed. It should instead generate a cancellation request We should add a new endpoint: DELETE /api/v1/public/patrons/:patron_id/holds/:hold_id And it should return a 202 accepted response as the actual deletion doesn't happen until the library confirms -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 33471] New: Improve performance of hold pickup location verification for next available holds
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33471 Bug ID: 33471 Summary: Improve performance of hold pickup location verification for next available holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When placing a new hold, or updating the location of an existing hold, we verify that the pickup location is valid. To do so we call 'pickup_locations' on the bib, or the item. The item case is trivial, however, for bibs we call Item->pickup_locations for every item on the bib. If we are simply validating a single location this can be quite expensive and unnecessary. I propose adding a new function to specifically validate pickup location for a biblio -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 30013] New: Limit/throttle SMTP connections
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30013 Bug ID: 30013 Summary: Limit/throttle SMTP connections Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org We have a setup where Koha is sending email through the SMTP server of the library's mother institution. We are seeing a problem with sending lots of emails in one go, where the first emails are sent ok, but then the rest fail with an error like this: unable to establish SMTP connection to (mail.x.y) port 25 It looks like this is due to some limit on the server, making it unresponsive if there are too many connections from the same source in a short time. I don't know a lot about SMTP but I can imagine a couple of solutions: - Introduce a configurable "sleep" period between each call to the external SMTP server (or batches of a configurable number, with a configurable sleep between each batch) - Looking at the response from the server and if "unable to establish SMTP connection" is received, wait for a configurable amount of time before trying to resend the failed message and the rest of the queue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 25466] New: Review 'problem_reports' column names and types
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25466 Bug ID: 25466 Summary: Review 'problem_reports' column names and types 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 reportid => id borrowernumber => patron_id (created_by_id?) branchcode => library_id problempage => problem_page status => Looks like an ENUM About borrowernumber, I'm not sure it should default to 0, we are leaning to default to NULL. In the code it would probably default to the anonymous patron id? I might be wrong, just putting my notes here for discussion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 25215] New: 'Report a problem' could be enhanced to become a generic 'Inquiry management' process.
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25215 Bug ID: 25215 Summary: 'Report a problem' could be enhanced to become a generic 'Inquiry management' process. 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: oleonard(a)myacpl.org, testopia(a)bugs.koha-community.org Depends on: 4461, 25213, 25214 With bug 4461 we introduce a mechanism for patrons to report issues with the OPAC and for staff to manage the progress of such inquiries through various status's. We could generalize the code used to allow for other types of inquiries from patrons. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4461 [Bug 4461] Context-sensitive report a problem screen https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25213 [Bug 25213] It would be beneficial to be able to notify the patron of a resolution https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25214 [Bug 25214] It would be beneficial for patrons to be able to see their OPAC problem reports -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 27052] New: OPACReportProblems
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27052 Bug ID: 27052 Summary: OPACReportProblems 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Should give admin the ability to define who gets the e-mail/what e-mails to use. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 33208] New: When a recalled item is checked-in there is no indication of that the item is recalled and the recall status is not updated from requested
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33208 Bug ID: 33208 Summary: When a recalled item is checked-in there is no indication of that the item is recalled and the recall status is not updated from requested Change sponsored?: --- Product: Koha Version: 22.05 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: rajujogi.t(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32990] New: Refactor C4::ImportBatch::_update_batch_record_counts to prevent deadlock
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32990 Bug ID: 32990 Summary: Refactor C4::ImportBatch::_update_batch_record_counts to prevent deadlock 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See 32558. Running this sub in parallel within multiple transactions creates a deadlock. C4::ImportBatch::_update_batch_record_counts(): DBI Exception: DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction at /usr/share/koha/C4/ImportBatch.pm line 392 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 33335] New: MARC overlay rules broken because of "categorycode.categorycode " which contains "-"
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33335 Bug ID: 33335 Summary: MARC overlay rules broken because of "categorycode.categorycode " which contains "-" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: marius.mandrescu(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 148696 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148696&action=e… the page half loaded The "MARC overlay rules" page becomes inaccessible if in the DB there is in the "categories" table a "categorycode" which contains a "-". This happens because of the javascript function on the page "marc-overlay-rules.tt" line 469. The problem that is caused is the "SyntaxError: missing : after property id". Plan test: 1- Go to Administration->Patron categories 2- Make sure you don't already have a patron categories that contains a "-" 3- Go to Administration->Record matching rules 4- Everything should be displayed as it does 5- Return to Patron categories 6- Add a new category In the category code put a "-" and save 7- Return to Record matching rules The page should be half loaded as in the photo The solution should not prevent the user from putting "-" in the category code but the Record matching rules accept the category code with "-". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25