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

[Bug 32483] New: Show requested changes to personal details in OPAC
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '26

16 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32483 Bug ID: 32483 Summary: Show requested changes to personal details in OPAC 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment when a user makes a request for changing the address or similar, there is a note on submitting the form, that the request will be forwarded to the library for processing. After that, when the page is reloaded, the old information still shows and there is no hint on a pending change request. It would be nice if we could show that there was still a change request pendingon the page, so that people don't resend them unnecessarily. And it would be great if we could show which changes were requested. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 26993] New: Allow StoreLastBorrower to retain up to 2 previous patrons
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '26

16 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26993 Bug ID: 26993 Summary: Allow StoreLastBorrower to retain up to 2 previous patrons 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: 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: 14945 Various workflows and circumstances can result in the "last returned by" value stored by StoreLastBorrower getting overwritten sooner than a library might like. For example, a patron may find the item they've checked out was damaged by the previous patron. They put the item in the bookdrop on their way into the library and then alert staff to the damage when they check out their next batch of items. By that time, the damaged item has been checked in, our imaginary patron shows as "last returned by," and we have no record there of who had it previously. We could alleviate this by adding a third option to the StoreLastBorrower system preference, so that one can choose "Do not store," "store 1," or "store 2." This entire feature would still be optional for libraries that don't want to keep this data. Additionally, bug 23260 is adding the ability to clear this data after a period of time using cleanup_database. These factors help mitigate the privacy concerns inherent to the matter. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14945 [Bug 14945] Add the ability to store the last patron to return an item -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 84

[Bug 37248] New: [Omnibus] Power to the user
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '26

16 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37248 Bug ID: 37248 Summary: [Omnibus] Power to the user Change sponsored?: --- Product: Koha Version: unspecified 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is for the initiative for helping to ensure that users can do as much of the configuration in the interface rather than the command line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 20153] New: Add new column "source" in the authorities pages's result
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '26

15 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20153 Bug ID: 20153 Summary: Add new column "source" in the authorities pages's result Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl hi, It would be nice if we could add a new column in the results page of a search in authority's module.In this new column we could se the subfield 040 $a who show the Organization that performed the original cataloging. With this new column with this new column titled "source", like the column in the z39.50 search, we would not need to go back to the authority record to see if it's a locally created authority or if it's imported. Patrick. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 40594] New: Allow batch record modification to create multiple items on existing bibs
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '26

15 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40594 Bug ID: 40594 Summary: Allow batch record modification to create multiple items on existing bibs Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 185115 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=185115&action=e… MMT sample multiple mapped items Bug 26869 only considered one item to be added per library modification execution, if more than one item is mapped, it fails with an FK constraint. I don't know the reason behind it, but the original test plan stated: test with more than one occurrence of 952$a -> confirm 'FK constraint' error is shown, no modification made I don't think there's any reason why this restriction should exist. The attached Marc Modification Template sample should work perfectly fine and add new - multiple - items to biblio records, as mapped. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 41315] New: Using patron-homelibrary option for overdue notices may not send notices to all branches
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41315 Bug ID: 41315 Summary: Using patron-homelibrary option for overdue notices may not send notices to all branches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Bug 32740 added the option to send overdue notices from the patron's homelibrary. The branchcode variable is used for several purposes, in the new code: 649 if ($patron_homelibrary) { 650 $branchcode = $patron->branchcode; 651 $library = Koha::Libraries->find($branchcode); 652 $admin_email_address = $library->from_email_address; 653 $branch_email_address = C4::Context->preference('AddressForFailedOverdueNotices') 654 || $library->inbound_email_address; 655 } We change that branchcode param based on the patron, however, earlier when getting the list of patrons we limit by issue branch: 567 my $borrower_sql = <<"END_SQL"; 568 SELECT issues.borrowernumber, firstname, surname, address, address2, city, zipcode, country, email, emailpro, B_email, smsalertnumber, phone, cardnumber, date_due 569 FROM issues,borrowers,categories,items 570 WHERE issues.borrowernumber=borrowers.borrowernumber 571 AND borrowers.categorycode=categories.categorycode 572 AND issues.itemnumber = items.itemnumber 573 AND items.itemlost = 0 574 AND TO_DAYS($date)-TO_DAYS(issues.date_due) >= 0 575 END_SQL 576 my @borrower_parameters; 577 if ($branchcode) { 578 if ($owning_library) { 579 $borrower_sql .= ' AND items.homebranch=? '; 580 } else { 581 $borrower_sql .= ' AND issues.branchcode=? '; 582 } 583 push @borrower_parameters, $branchcode; 584 } So we may have a patron from a different branch when we go through here, and end up changing the branch we will look at during the next pass of the code above I recreated by checking out three items to patrons from different branches, 1 day overdue each: MariaDB [koha_kohadev]> SELECT borrowers.cardnumber, borrowers.surname, borrowers.branchcode, borrowers.categorycode, issues.issue_id, issues.branchcode, issues.date_due FROM issues JOIN borrowers USING (borrowernumber); +----------------+---------+------------+--------------+----------+------------+---------------------+ | cardnumber | surname | branchcode | categorycode | issue_id | branchcode | date_due | +----------------+---------+------------+--------------+----------+------------+---------------------+ | 23529001000463 | Acosta | MPL | PT | 1 | CPL | 2025-11-25 23:59:00 | | 23529000139858 | Ballard | FFL | PT | 2 | CPL | 2025-11-25 23:59:00 | | 23529000035676 | Acevedo | IPT | PT | 3 | CPL | 2025-11-25 23:59:00 | +----------------+---------+------------+--------------+----------+------------+---------------------+ 3 rows in set (0.001 sec) Setting overdue rules to trigger at 1 day, then got this output: branch 'CPL', categorycode = PT pass 1 Using letter code 'ODUE' for pass 1 Found 3 borrowers with overdues borrower Acosta, Edna (5) has items triggering level 1. borrower Acevedo, Henry (19) has items triggering level 1. borrower Ballard, Ronnie (21) has items triggering level 1. branch 'FFL', categorycode = PT pass 2 No letter code found for pass 2 branch 'FFL', categorycode = PT pass 3 No letter code found for pass 3 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 41163] New: Circulation logs record issuing branch in database but show logged-in branch in log viewer
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41163 Bug ID: 41163 Summary: Circulation logs record issuing branch in database but show logged-in branch in log viewer Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 9762 To recreate: - confirm circ logging is on - check out an item at Centerville (CPL) - go to the log viewer, find your checkout, confirm the Info column includes "CPL" - switch your logged-in library to Fairfield (FFL) - confirm the log viewer now shows "FFL" in the info column for your checkout - use a report to view action_logs.info for your checkout, confirm the field contains "CPL" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9762 [Bug 9762] Log circulation overrides -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 40822] New: Custom cover images not displayed in search results
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40822 Bug ID: 40822 Summary: Custom cover images not displayed in search results Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Description: When using OPACCustomCoverImages, the custom cover image shows correctly on the bibliographic detail page but does not appear in the search results list. To Reproduce: 1. Disable all cover image preferences (OPACLocalCoverImages, OPACAmazonCoverImages, SyndeticsCoverImages, GoogleJackets OpenLibraryCovers, BakerTaylorEnabled, OPACCoce). 2. Enable OPACCustomCoverImages. 3. Set CustomCoverImagesURL to {956$u}. 4. Ensure field 956$u is visible in the record editor. 1. Go to Administration --> MARC bibliographic framework. 2. Click Actions --> MARC Structure for the default framework. 3. Search for field 956. 4. Click Actions --> Edit subfields. 5. Open the u subfield tab. 6. Make sure the subfield is in tab 9. 7. Check OPAC, Intranet, and Editor. 8. Click Save changes. 5. In a bibliographic record, add the following URL to 956$u: https://m.media-amazon.com/images/I/71Uo7Fqbu3L.jpg 6. At the OPAC, perform a search to display the record in a results list. --> The custom cover image does not appear in the search results list. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 36136] New: Flatpickr allows selecting date from the past on copied serial subscriptions
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36136 Bug ID: 36136 Summary: Flatpickr allows selecting date from the past on copied serial subscriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org If a librarian copies a serial subscription and changes dates the Flatpickr allows to put end date to the past. Flatpickr prevents the action only if the start date is first added. In this case the old input value should be passed to the Flatpickr so the selection is not allowed. I think this happens everywhere where we are using Flatpickr. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 41506] New: Should we remove RabbitMQ?
by bugzilla-daemon＠bugs.koha-community.org 14 Mar '26

14 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41506 Bug ID: 41506 Summary: Should we remove RabbitMQ? Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the hackfest in Wellington this came up as a question in the discussion and it was decided to bring it up at the next development meeting. https://koha-hedgedoc.servers.llownd.net/Development_IRC_meeting_26_Novembe… The discussion is difficult and we want to include as many opinions/people as possible. I felt it would be a bit lost on bug 35920, so proposing a separate bug report instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31