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

[Bug 38193] New: Add cancellation_reason field to bookings table
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '25

24 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38193 Bug ID: 38193 Summary: Add cancellation_reason field to bookings table 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: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In line with other modules, we'd like to specify a reason for a cancellation, either free text or an authorised value. Then we want to use it when cancelling and within the cancellation notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 34883] New: Regression in Patron Import dateexpiry function
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '25

24 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34883 Bug ID: 34883 Summary: Regression in Patron Import dateexpiry function Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello all, We are seeing issues in our import_patrons.pl which is causing issue for our academic customer base. In versions prior to 22.11, running import_patrons.pl would cause the dateexpiry to either: — get set based on the contents of the dateexpiry in the CSV file; or — get left as the value already in Koha This worked well for our academics, because they could opt when to update the dateexpiry rather than sending them over every night (e.g. if a student exited a course early, they could be expired in the LMS to prevent them from accessing the services). In 22.11, the update-expiration and expiration-from-today flags have been added to the script. I believe the logic behind these flags is to update the dateexpiry based on enrolment plus user category duration, or today plus user category duration. This probably works great for most libraries, but it isn't necessarily desirable for Colleges. The option still exists to set dateexpiry from the CSV, by not passing the aforementioned flags. However, the dateexpiry now gets set to the following, when using this: — get set based on the contents of the dateexpiry in the CSV file; or — get left as the value already in Koha As you can see, this is a clear regression. Could we please look to remediate this, so I can pass on some good news to our affected customers? Many thanks, Jake Deery PTFS Europe -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 36383] New: Add option to set open booking days
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '25

24 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36383 Bug ID: 36383 Summary: Add option to set open booking days 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With the new bookings module, there is work being done on 34440 to add prep days on either end of the booking to allow the library to gather materials for sending. In some libraries bookings is its own system/department, and is not open every day of the week. It would be helpful to be able to define "booking days" similar to 'curbside hours' and to take these into account when bookings are being placed. i.e.: A booking is being placed to begin on a Monday, it requires 2 warm up days, the bookings dept is closed on weekends. The booking period will need to include the Thursday and Friday of the week before. Similarly, a booking ending on Friday would need cooldown days on Monday and Tuesday -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 38591] New: Add a new ILL status "Available in library"
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38591 Bug ID: 38591 Summary: Add a new ILL status "Available in library" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com A status "Available in library" (or "Received") should be useful to better monitor the progress of the transaction As I understand it, the current workflow (if you check out ILL items) is : - NEW : new request created by a patron or a librarian - REQ : request validated by the library and send to a document provider - CHK : document received by the library and checked out to the patron - RET : document checked in by the patron - COMP : end of transaction. document sent back to the document provider I think it could better be : As I understand it, the current workflow (if you check out ILL items) is : - NEW : new request created by a patron or a librarian - REQ : request validated by the library and send to a document provider - AVA : document received by library, availalable for check out => at THAT stage we can send a message to the patron asking them to come to the library - CHK : document and checked out to the patron - RET : document checked in by the patron - COMP : end of transaction. document sent back to the document provider -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37874] New: Print selected item
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37874 Bug ID: 37874 Summary: Print selected item Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: chanel.wheeler(a)yavapaiaz.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com One of our libraries has requested a "print selected item" choice in check out. Here it is in their words: "It should print out a check out slip. When you are in the checkout tab, I was thinking if there was a column to be able to check a box on the line of each item, a specific item could be selected. Then the drop-down box under Print would have an option in addition to the current ones that said Print Selected Item. This is useful when a patron inquires about a checkout at the front desk, and we are able to just print a checkout slip for that one item versus all of them. I also could use it when I have checked out something to PVPL Mending, and I want to print a slip for that one item to be able to put it in with that item. That slip would let mending know that it has been checked out to mending along with any handwritten notes that might be added." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 18925] New: Move maxissueqty and maxonsiteissueqty to circulation_rules
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18925 Bug ID: 18925 Summary: Move maxissueqty and maxonsiteissueqty to circulation_rules 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18887 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18887 [Bug 18887] Introduce new table 'circulation_rules', use for 'max_holds' rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 171

[Bug 18928] New: Move holdallowed, hold_fulfillment_policy, returnbranch to circulation_rules
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18928 Bug ID: 18928 Summary: Move holdallowed, hold_fulfillment_policy, returnbranch to circulation_rules 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18925 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18925 [Bug 18925] Move maxissueqty and maxonsiteissueqty to circulation_rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 171

[Bug 18887] New: Introduce new table 'circulation_rules', use for ' max_holds' rules
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18887 Bug ID: 18887 Summary: Introduce new table 'circulation_rules', use for 'max_holds' rules 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 18886 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18886 [Bug 18886] Restructure storage of circulation rules to reduce complexity and enable increased flexiblity -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 168

[Bug 22847] New: Specific circ rule by patron category is displaying the default (or not displaying)
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22847 Bug ID: 22847 Summary: Specific circ rule by patron category is displaying the default (or not displaying) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: critical Priority: P5 - low Component: System Administration Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 18887, 18925 Target Milestone: --- There are several things going wrong on the circulation rules screen. The global rule is displayed for specific libraries (even if the rule does not exist for the library), and max_holds is always blank. I have trouble finding the root of the issue, but I will propose a patch to fix both problem. Certainly a mismatch between bug 18887 and bug 18925. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18887 [Bug 18887] Introduce new table 'circulation_rules', use for 'max_holds' rules https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18925 [Bug 18925] Move maxissueqty and maxonsiteissueqty to circulation_rules -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 36246] New: Have a centralized method for submitting a form via a link
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '25

23 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36246 Bug ID: 36246 Summary: Have a centralized method for submitting a form via a link 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org With new CSRF protection we have a fair number places where action buttons have become full forms, or links need to use JS to submit a form. We have generally agreed that the form should be in the page, and the js can add the necessary values for POSTing I think we should go a step further and have a class that can be used to submit a form via a link with data elements, i.e. <a class="btn btn-default btn-xs submit-form-link" href="#" data-adjustment_id="[% adjustment.adjustment_id | html %]" data-invoiceid="[% invoiceid | html %]" data-action="invoice.pl" data-method="post" data-op="cud-del_adj" data-confirmation="confirm_delete_adjustment"> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38