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

[Bug 9181] Add patron messaging preferences to batch patron modification tool
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9181 carthur(a)slolibrary.org <carthur(a)slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur(a)slolibrary.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35028] New: Add pre-registrations alert on staff interface main page
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35028 Bug ID: 35028 Summary: Add pre-registrations alert on staff interface main page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.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 watching all bug changes.

1 32

[Bug 38532] New: Show both credits and debits in patron_messages.inc
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38532 Bug ID: 38532 Summary: Show both credits and debits in patron_messages.inc 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently patron_messages.inc gives an accurate but misleading overview of the patron's account in the patron overview. If the patron has at least 1 debit on their account with an amountoutstanding > 0, we show a message "Patron has outstanding charges of X," where X is the total of all outstanding debits. If the patron has no outstanding debits and at least 1 credit with an amountoutstanding < 0, we show a message of "Patron has a credit of X," where X is the total of all outstanding credits. If a patron has 1 debit of $1 and 2 credits of $1,000,000 each, Koha only tells you about the $1 debit. I suggest we reword the credit message to "Patron has outstanding credits of X" and make it show whenever there is one or more credit with an outstanding amount on the account. So patrons with both credits and debits on their account will show both messages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 41379] New: Specifying a return date for a bundle is ignored
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41379 Bug ID: 41379 Summary: Specifying a return date for a bundle is ignored Initiative type: --- Sponsorship --- status: 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com To recreate: 1 - Create a bundle (https://bywatersolutions.com/education/creating-bundles-of-items-in-koha) 2 - Issue the bundle 3 - Go to Circulation->Returns 4 - Select a date 5 - Check in the bundle 6 - Verify/scan each item barcode 7 - Check the patrons circulation history 8 - Note the bundle was marked returned on today's date -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 40844] New: SCO warning language misleading - remove duplicate warning
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40844 Bug ID: 40844 Summary: SCO warning language misleading - remove duplicate warning Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.aimee(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org SCO warning "Item is reserved for another patron upon return" - this leads patrons and staff to believe that the item is checked out but it cannot be renewed, as in they will return the item at the due date and not immediately to circulation. Clarity would look like "Item cannot be checked out, reserved for another patron." Connected to AllowItemsOnHoldCheckoutSCO: (do/don't allow) checkouts of items reserved to someone else in the SCO module. If allowed do not generate RESERVE_WAITING and RESERVED warning. This allows self checkouts for those items. At times, we do get a message similar to the proposed message above - perhaps reducing down to a singular warning message (choosing RESERVE or RESERVE_WAITING) would be best. It would also be cool to see this be customizable. Similar to 39162 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 37200] New: SIP2 Renewal uses AddIssue
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37200 Bug ID: 37200 Summary: SIP2 Renewal uses AddIssue Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When we make a renewal request via SIP, the code calls 'AddIssue' - which then calls 'AddRenewal' when it sees we are issuing to current borrower. It seems we could cut out the middleman and call AddRenewal directly? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37016] New: SIP2 renew shows old/wrong date due
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37016 Bug ID: 37016 Summary: SIP2 renew shows old/wrong date due Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org This was reported by a library running 23.11.03. Sometimes when patrons do renewals via SIP2, the old due date is reported as the new due date. But everything else looks OK, including the staff view and "my profile", which shows the right due date. It looks like this only happens some of the time, or for some patrons, but I have not been able to figure out what the difference is there. I do think I have spotted the problem, though. C4::Circulation::AddIssue() has this code: 1552 my $issue; ... 1571 # find which item we issue 1572 my $item_object = Koha::Items->find({ barcode => $barcode }) 1573 or return; # if we don't get an Item, abort. 1574 my $item_unblessed = $item_object->unblessed; 1575 1576 my $branchcode = _GetCircControlBranch( $item_object, $patron ); 1577 1578 # get actual issuing if there is one 1579 my $actualissue = $item_object->checkout; 1580 1581 # check if we just renew the issue. 1582 if ( $actualissue and $actualissue->borrowernumber eq $patron->borrowernumber 1583 and not $switch_onsite_checkout ) { 1584 $datedue = AddRenewal( 1585 { 1586 borrowernumber => $patron->borrowernumber, 1587 itemnumber => $item_object->itemnumber, 1588 branch => $branchcode, 1589 datedue => $datedue, 1590 lastreneweddate => 1591 $issuedate, # here interpreted as the renewal date 1592 } 1593 ); 1594 $issue = $item_object->checkout; 1595 } We get the $item_object on line 1572. Then we get the active issue/loan/checkout from the $item_object on line 1579. Renewal is done on line 1584 (and testing shows $datedue has the right date due there). But then we update $issue with the active issue/loan/checkout from the same $item_object as earlier, which has not been updated, and contains stale data, including the original date due. I was able to quickfix this by replacing line 1594 with this: my $updated_item_object = my $item_object = Koha::Items->find({ barcode => $barcode }); $issue = $updated_item_object->checkout; But I am far from confident that this is a good fix, so opinions are welcome! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 31603] New: Add search option for plugin page
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31603 Bug ID: 31603 Summary: Add search option for plugin page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be great to add a search box on this page /plugins/plugins-home.pl to allow users to search the installed plugins. Steps to recreate go to administration click on manage plugins -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #205 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Jonathan Druart from comment #204) > In the last patch: > - min; > + `${min}`; > > Why this kind of changes exactly? The idea here is to consistently prevent JS data-types shenanigans and oddness from occurring, really - we're ensuring that once the number is calculated, we convert it to a string. Effectively, I went with: - anything that gets assigned to the Vue template: convert to string first. - when manipulating numbers (which we mostly get as string from the relevant input field): convert to integer first. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14907] Item search: call numbers in item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '25

18 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #33 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #20) > Sorry, I am not sure I get your point. :( > > For me this patch for sorting and the generation of cn_sort are separate. > > cn_sort is generated whenever an item is edited/changed, or the touch script > is run, depending on the classification source. Of course there can be bugs > in this area too. > > For sorting we use cn_sort already in other places like inventory or the > callnumber value builder and the field should be used every where we sort on > callnumbers. > > For me the goal of this patch is to use the cn_sort data. So I'd probably > look at the itmecallnumber, cn_sort and sort by cn_sort with SQL and compare > that to what I see in item search. I thought cn_sort was updated when an item is edited/changed or the touch script is run, but it looks like that might not be the case. Looking at Koha/Item.pm, it looks like cn_sort is only generated for new items OR if you're modifying an item and specifically changing the itemcallnumber or cn_source. This makes some sense because it reduces the likelihood of re-computing the same values, but... it does actually mean it's difficult to re-generate cn_sort. I've had some libraries with cn_sort issues, and I've had to do custom scripts today to re-generate the cn_sort. -- You are receiving this mail because: You are watching all bug changes.

1 0