July 2026 - Koha-bugs - lists.koha-community.org

[Bug 42861] New: System warning about missing encryption_key on a fresh instance
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42861 Bug ID: 42861 Summary: System warning about missing encryption_key on a fresh instance Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: saiful(a)semanticconsulting.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- On a fresh Koha installation, the About Koha > System information page shows this XML configuration warning: Warning You are missing the <encryption_key> entry in your koha-conf.xml file. Please generate a key. We recommend one of at least 32 bytes. (You might use 'pwgen 32' to do so.) I think this has an easy fix, by just adding couple of lines in the koha-create script. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 42699] New: Editing an already received serial with a duplicate barcode leads to Error 500
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42699 Bug ID: 42699 Summary: Editing an already received serial with a duplicate barcode leads to Error 500 Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: lauri.hanninen(a)lahti.fi QA Contact: testopia(a)bugs.koha-community.org When you edit an already received serial from Serial collection page using Edit serials and edit items buttons, and try to save a barcode that already exists on another item, saving leads to Error 500. Apparently there's no validation on the serial module's edit page which causes that problem. Steps to Reproduce: -Go to serials module -Search for a serial that is not expired to edit and click on the title -Go to Serial collection from the menu -Use the checkboxes to mark an already received (eg. usually older, arrived, not expected) serial and click Edit serials -Click on Edit item -Replace the barcode with a unique barcode that is already in use and hit save -> Error 500 Actual Results: Saving changes returns Error 500. Expected Results: Validation returns a duplicate barcode value/already in use error and doesn't try to save before a valid and unique barcode is given. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 33364] New: Stop Holds to Pull report showing items that have been allocated to a recall
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33364 Bug ID: 33364 Summary: Stop Holds to Pull report showing items that have been allocated to a recall Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests 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 The Holds to Pull report shows an item with a hold if the item is available on the shelf, ready to pull and allocate to the hold. The Holds to Pull should NOT show an item with a hold if that item has already been allocated to a recall (i.e. the recalled item is awaiting pickup and or in transit for a patron). To reproduce: 1. Enable UseRecalls and set the recalls-related circulation rules 2. Check out an item to Patron A 3. Place a hold on the item for Patron B 4. Log into the OPAC as Patron C and search for the item. Place a recall on the item. 5. Go back to the staff interface. Go to Circulation -> Holds to pull 6. Confirm the item shows in the Holds to pull table, with the hold for Patron B 7. Check in the item and confirm the recall as waiting 8. Go back to the Holds to pull page. You could manually regenerate the page but running the cronjob in the terminal misc/cronjobs/holds/build_holds_queue.pl 9. Notice that even though the item is allocated for a recall, the hold is showing. It should not be showing in this page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 42522] New: Holdings created in ERM with a linked bibliographic record do not show the link to the record
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42522 Bug ID: 42522 Summary: Holdings created in ERM with a linked bibliographic record do not show the link to the record Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 36762] New: Item not transferred correctly when there is a pending hold
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36762 Bug ID: 36762 Summary: Item not transferred correctly when there is a pending hold Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal 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 Koha is doing some dumb stuff when one attempts to transfer an item that could fill a pending hold. To recreate: 1 - be logged in at Branch A 2 - have a bib with 1 holdable item at Branch A 3 - place a hold for pickup at Branch B 4 - confirm hold shows on Holds to Pull and Holds Queue 5 - go to Circulation > Transfers and attempt to send your item to Branch C 6 - Koha gives you three options. Pick the first one: "Transfer to Branch B." This is the hold pickup branch, not the branch you selected for your transfer 7 - Koha tells you it has transferred the item to Branch C (the branch you did select for your transfer) 8 - go to detail.pl for your title, confirm the holdings table says "there is an item level hold" on your item 9 - click to the Holds tab for your title, confirm the hold claims to be in transit 10 - query the branchtransfers table, confirm no transfer was created 11 - query reserves and confirm your hold has found=T, itemnumber=[your item], and item_level_hold=0 12 - Back on the title, attempt to revert transit status, confirm the Revert button doesn't do anything At step 6, Koha should offer to transfer to the indicated transfer-target, rather than the hold pickup branch. Then it should actually generate the transfer and should not insert the itemnumber into the reserves table or update reserves.found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 42992] New: FTP file transport list_files() corrupts filenames
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42992 Bug ID: 42992 Summary: FTP file transport list_files() corrupts filenames Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::File::Transport::FTP->_list_files parses the LIST / "ls -l" output returned by the FTP server. The date field in that output is three whitespace-separated tokens (Mon DD HH:MM, or Mon DD YYYY for older files), but the parse used a non-greedy capture that only consumed the first token (the month). The remaining two date tokens were left glued to the front of the filename, so every filename returned for an FTP transport was prefixed with the listing date, e.g. -rw-r--r-- 1 user group 1234 Jan 01 12:00 QUOTES_413514.CEQ becomes filename "01 12:00 QUOTES_413514.CEQ" Callers (Koha::Edifact::Transport and misc/cronjobs/marc_ordering_process.pl) then ask the server for a file that does not exist, so no files are downloaded, renamed or deleted over FTP. SFTP and Local transports are not affected. This regressed when EDI transport moved onto the file_transports system (bug 38489): the old Koha::Edifact::Transport::ftp_download listed files with Net::FTP->ls (NLST, bare names); the refactor switched to Net::FTP->dir (LIST) to return the richer hashref shape used by the SFTP and Local transports, but the parse was faulty. The fix consumes the date field explicitly as three tokens so the filename is captured cleanly (spaces preserved, directories still skipped). The LIST-based approach and the filename/longname/size/perms return shape are kept so the structure stays consistent across transport classes. Test plan: 1. prove t/db_dependent/Koha/File/Transport/FTP.t 2. Revert Koha/File/Transport/FTP.pm only and re-run: the list_files() subtest fails on the filename/size/perms assertions. 3. prove t/db_dependent/Koha/Edifact/Transport.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 42915] New: Filtering Holds table by patron name or pickup library is broken
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42915 Bug ID: 42915 Summary: Filtering Holds table by patron name or pickup library is broken Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- To replicate: 1. Have holds on a bib for different patrons and pickup locations 2. Try filtering by a patron name or pickup location 3. See 'No matching records found' 4. Note: filtering by patron barcode still works This regression seems like it was introduced by bug 23269 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 82

[Bug 43174] New: Regressions: Staff interface patron search on a record details page - lists patrons by default
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43174 Bug ID: 43174 Summary: Regressions: Staff interface patron search on a record details page - lists patrons by default Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- When placing holds in the staff interface the patron search lists the first 20 results by default - previously this did not happen. To reproduce: 1. Go to a record in the staff interface. 2. Click on "Place hold". 3. Give things a second. 4. Under the patron search input box, a list of patrons appear (first 20 results). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 42988] New: Saving a sip account imported from SIPconfig.xml can change the holds ( holds_get_captured ) behavior.
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42988 Bug ID: 42988 Summary: Saving a sip account imported from SIPconfig.xml can change the holds ( holds_get_captured ) behavior. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The migration from the SIP config file to the database leaves holds_get_captured NULL which makes the behavior default to on, but in the sip account editor, the off option is selected so when you save the profile edit, the behavior is changed! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 41084] New: Zotero connector broken by bug 37370
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41084 Bug ID: 41084 Summary: Zotero connector broken by bug 37370 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 37370 This is difficult.. as I said in the comment on bug 37370, we find libraries don't want to visually show utf8 in the export menu, but do want Zotero to work. As such, completely denying the utf8 option, which is the default fallback when no format is passed too, breaks the Zotero browser extension. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37370 [Bug 37370] opac-export.pl can be used even if exporting disabled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41