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

[Bug 32776] New: Choose to convert oldest reserve or all possible reserves to recalls
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32776 Bug ID: 32776 Summary: Choose to convert oldest reserve or all possible reserves to recalls 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 31415 introduces a script to convert reserves to recalls. By default, it will take the oldest reserve on a record and convert it to a recall. We should be able to customise which reserve(s) are converted to recalls. Options may include: - oldest reserve - one reserve for each issued item available to be recalled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 31415] New: Script to automate converting reserves to recalls
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '25

31 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31415 Bug ID: 31415 Summary: Script to automate converting reserves to recalls 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a record reaches X number of reserves, the library may convert reserves to recalls to prompt patrons to return them sooner. This can be automated with a script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 35665] New: Should secondary email address be allowed to be used as a CC in notices?
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35665 Bug ID: 35665 Summary: Should secondary email address be allowed to be used as a CC in notices? 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org I would say yes to this. Maybe have a checkbox next to the secondary email field to cc notices to this address. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36712] New: Alert "Maximum checkouts calculated from the circulation rule" is wrong with child itemtypes
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36712 Bug ID: 36712 Summary: Alert "Maximum checkouts calculated from the circulation rule" is wrong with child itemtypes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When trying to checkout an item with a child itemtype, it fails to say that the parent rule applied and says "All item types" Test plan: 1. have an itype BK (Books in sample data) 2. create an itype BK2, set BK as the parent to BK2 3. create a circ rule for All Patrons, item type BK (displays as "Books (All)" in the circ rules interface), setting total checkouts to 1 4. do not create any rule specifically for the BK2 itype 5. have 2 BK2 items (can be on the same bib record) 6. Try to checkout the 2 items 7. The alert mention matched circ rule is for "Item type: All item types" 8. This is wrong -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35704] New: Parent and child itemtype hold limits not enforced as expected
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35704 Bug ID: 35704 Summary: Parent and child itemtype hold limits not enforced as expected 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Similar to bug 30324, the hold limits aren't enforced for parent/child item types. A parent limit doesn't seem to matter at all in this case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 40706] New: Improve the display of priority on reserve/request.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40706 Bug ID: 40706 Summary: Improve the display of priority on reserve/request.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 40654 changed the display of the "priority" column on 40654 reserve/request.pl I think that display can be made better, particularly when there is a single hold in the table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 35320] New: Deleting a patron doesn't use AnonymusPatron to anonymize the circulation history
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35320 Bug ID: 35320 Summary: Deleting a patron doesn't use AnonymusPatron to anonymize the circulation history Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org I was under the impression that when AnonymousPatron is filled with a borrowernumber, deleting a patron (individually or with batch deletion tool) would anonymize their circulation history using AnonymousPatron, but it doesn't. After deleting a or some patrons, the circulation history in the book record shows blank spaces in lieu of the patrons. It would make more sens that when deleting a patron using the batch deletion tool or the delete button in a patron's page, the AnonymousPatron is used to fill the circulation history of the deleted patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 33481] New: EBSCO ws return 415: Content type 'application/octet-stream' not supported
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33481 Bug ID: 33481 Summary: EBSCO ws return 415: Content type 'application/octet-stream' not supported Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32030 ERROR - EBSCO API /vendors/19/packages/3816 returned 415 - Content type 'application/octet-stream' not supported [ERROR] PATCH /api/v1/erm/eholdings/ebsco/packages/19-3816: unhandled exception (Mojo::Exception)<<ERROR requesting EBSCO API /vendors/19/packages/3816 code 415: Content type 'application/octet-stream' not supported>> Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 40828] New: Items view: “Delete item” action not working
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40828 Bug ID: 40828 Summary: Items view: “Delete item” action not working Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Description: In Items view, the Delete item action does not work. Edit item works normally. Steps to reproduce: 1. Go to a bibliorecord and choose Edit → Manage items. (If there are no items, create one.) 2. In the table of existing items, click on any column except the first for any item. 3. In the pop-up menu, select Delete item. 4. Confirm the deletion. After confirming deletion, the item remains in the table, even though it should be removed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 30085] New: Improve performance of CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '25

30 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30085 Bug ID: 30085 Summary: Improve performance of CanItemBeReserved 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27