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

[Bug 38477] New: Regression: new overdue fine applied incorrectly when using "Refund Lost Item Charge and Charge New Overdue Fine" option in circ rules
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38477 Bug ID: 38477 Summary: Regression: new overdue fine applied incorrectly when using "Refund Lost Item Charge and Charge New Overdue Fine" option in circ rules Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 30254 Bug 30254 fixed this something like this previously. We're seeing erroneous fines created for patrons who previously returned something on time. In production, this occurs when an item is marked lost while not checked out to a patron. When that item is later found and checked in, Koha finds the most recent checkout and generates an overdue fine using the current date as the return date of the item (even though the item was returned at some point in the past). Set these sysprefs: - FinesMode: Calculate and Charge - WhenLostForgiveFine: Forgive - WhenLostChargeReplacementFee: Charge In circ rules: - Have a rule that charges fines - Set Refund lost item replacement fee to "Refund lost item charge and charge new overdue fine" 1 - Have/create item with replacement price 2 - Check item out to patron 1, due date in past 3 - Run fines.pl 4 - confirm fines on patron 1 5 - mark item lost 6 - confirm replacement cost generated and fine forgiven on patron 1 7 - check item in 8 - confirm replacement cost forgiven and new fine generated on patron 1 9 - check item out to patron 2, due date in future 10 - check item in 11 - mark item lost (no replacement fee generated because item is not checked out) 12 - in database, update date_due for checkout to patron 2, set to a date in the past 13 - check item in 14 - confirm patron 2 now has a fine At step 12 we're pushing the date_due of the old issue into the past to make date_due<curdate(). In production, this comes up when there are days between steps 10 and 13. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30254 [Bug 30254] New overdue fine applied to incorrectly when using "Refund lost item charge and charge new overdue fine" option in circ rules -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 39572] New: Create EDIFACT order button no longer gives librarians chance to review
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39572 Bug ID: 39572 Summary: Create EDIFACT order button no longer gives librarians chance to review Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Previously, the Create EDIFACT order button would take librarians to a page to select the correct EDI Library EAN. Now those EANs are listed on the button when clicked. The problem is this removes the chance to review the selection. There is no chance to review the selected EAN to confirm is was chosen correctly. In addition, some libraries have dozens of Library EANs making the button pulldown cumbersome to use. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 39787] New: Sending EDI order from basket fails if only one Library EAN exists
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39787 Bug ID: 39787 Summary: Sending EDI order from basket fails if only one Library EAN exists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If there is only one EAN defined, the button has no pulldown. Clicking the button to send the edi order results in the error: No sender ean passed to order creation: basket = Koha::Schema::Result::Aqbasket=HASH(0x5574bf315b98)->basketno() -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 37993] New: Having a single EDI EAN account produces a bad redirect
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37993 Bug ID: 37993 Summary: Having a single EDI EAN account produces a bad redirect Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In acqui/edi_ean.pl: if ( @eans == 1 ) { my $ean = $eans[0]->ean; print $query->redirect( "/cgi-bin/koha/acqui/basket.pl?basketno=$basketno&op=cud-ediorder&ean=$ean" ); } So if you only have the single 'Library EAN' account Koha redirects to: /cgi-bin/koha/acqui/basket.pl?basketno=$basketno&op=cud-ediorder&ean=$ean This causes an error "op 'cud-ediorder' must not start with cud-" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 33284] New: checkout_renewals table retains checkout history in violation of patron privacy
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33284 Bug ID: 33284 Summary: checkout_renewals table retains checkout history in violation of patron privacy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 30275 The checkout_renewals table introduced in bug 30275 can retain a link between a patron and an issue_id when the patron's privacy is set to Never. That data should be anonymized. To recreate: - have a patron with their privacy set to Never retain reading history - check an item out to the patron, renew it via the OPAC - confirm your patron's borrowernumber can be found in checkout_renewals.renewer_id and the issue_id for your checkout can be found in checkout_renewals.checkout_id - check your item in - confirm your patron's borrowernumber has been removed from old_issues.borrowernumber - confirm your patron's borrowernumber and the issue_id for your checkout can still be found in checkout_renewals.checkout_id (along with a note that the renewal happened via the OPAC, thereby making it perfectly clear that this was a patron renewing the item they had checked out themselves). Should we not replace checkout_renewals.renewer_id with the anonymous patron's borrowernumber when the item is returned, if the patron is set to not retain reading history? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30275 [Bug 30275] Checkout renewals should be stored in their own table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 40370] New: about.pl should NOT say "Run the following SQL to fix the database"
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40370 Bug ID: 40370 Summary: about.pl should NOT say "Run the following SQL to fix the database" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The database audit tool output is meant to be a guideline. It should not be treated as a database repair tool. That's why I included the original warning "WARNING!!! These commands are only suggestions". For instance, if you had a plugin that added a table, the database audit tool would tell you to drop it. And then your Koha plugin is broken. Not a great outcome. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 33455] New: Heading on 'update password' page it too big
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33455 Bug ID: 33455 Summary: Heading on 'update password' page it too big Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The h1 heading on the change password page is too big and should be outside of the legend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 38683] New: Opac cover images are only shown on fist result page
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38683 Bug ID: 38683 Summary: Opac cover images are only shown on fist result page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org When using cover images on the opac there is a strange behavior when there are more than 1 result pages. On the first result page everything works like expected, but on the subsequent result pages the cover images are not shown. to reproduce: - set system preference OPACAmazonCoverImages to show - open opac an search for "and" - the html structure for each result row is like: <td class="selectcol"></td> <td class="numcol"></td> <td class="covercol"></td> <td class="bibliocol"></td> - then go to the second result page and check that the row structure differs now <td class="selectcol"></td> <td class="numcol"></td> <td class="bibliocol"></td> -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 38886] New: TrackLastPatronActivityTriggers should have an option for patron modification
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38886 Bug ID: 38886 Summary: TrackLastPatronActivityTriggers should have an option for patron modification Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 23486 added the option for patron creation and it would be great if patron modification in staff interface would also update patron's lastseen field when the update is done in cgi-bin/koha/members/memberentry.pl. Batch patron modification should not update the lastseen field because it is often used to fix information without patron's own request and patron is not therefore "seen" in these cases. For example a library closes down permanently and patrons' home library is changed to another one. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 34118] New: Add Patron's home library as an option on the DefaultHoldPickupLocation preference
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34118 Bug ID: 34118 Summary: Add Patron's home library as an option on the DefaultHoldPickupLocation preference 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: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some groups want the option to default the pickup location to the patron's home library when placing holds on the staff client rather than the logged in branch or the item's location. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9