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

[Bug 43071] New: Test failures when Holds Allowed (daily) has a value
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43071 Bug ID: 43071 Summary: Test failures when Holds Allowed (daily) has a value Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- t/db_dependent/Holds.t, t/db_dependent/ILSDI_Services.t, and t/db_dependent/api/v1/holds.t all fail if the Holds Allowed (daily) circ rule has a value. They fail slightly differently for a non-zero value and for a zero. They pass if there is no value set for this rule. Non-zero: Test Summary Report ------------------- t/db_dependent/Holds.t (Wstat: 512 (exited 2) Tests: 74 Failed: 2) Failed tests: 64, 69 Non-zero exit status: 2 t/db_dependent/ILSDI_Services.t (Wstat: 256 (exited 1) Tests: 16 Failed: 1) Failed test: 6 Non-zero exit status: 1 t/db_dependent/api/v1/holds.t (Wstat: 2816 (exited 11) Tests: 12 Failed: 1) Failed test: 11 Non-zero exit status: 11 Parse errors: Bad plan. You planned 20 tests but ran 12. Zero: Test Summary Report ------------------- t/db_dependent/Holds.t (Wstat: 1024 (exited 4) Tests: 74 Failed: 4) Failed tests: 64-66, 69 Non-zero exit status: 4 t/db_dependent/ILSDI_Services.t (Wstat: 512 (exited 2) Tests: 8 Failed: 2) Failed tests: 6-7 Non-zero exit status: 2 Parse errors: Bad plan. You planned 16 tests but ran 8. t/db_dependent/api/v1/holds.t (Wstat: 2816 (exited 11) Tests: 12 Failed: 1) Failed test: 11 Non-zero exit status: 11 Parse errors: Bad plan. You planned 20 tests but ran 12 -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 43034] New: t/db_dependent/Koha/EDI.t fails when SearchEngine is Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43034 Bug ID: 43034 Summary: t/db_dependent/Koha/EDI.t fails when SearchEngine is Elasticsearch Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 42981] New: ERM package result list hangs when filtering by vendor and search status is saved
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42981 Bug ID: 42981 Summary: ERM package result list hangs when filtering by vendor and search status is saved Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu 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 Target Milestone: --- Problem: When the search status is saved on a page, the ERM package results list freezes when filtering by vendor. The issue is reproducible with the following steps: 1.) Admin - table settings: cgi-bin/koha/admin/columns_settings.pl#eholdings|packages Activate checkbox "Save search state on page change" 2.) Go to ERM : cgi-bin/koha/erm/eholdings/local/packages And create two packages: - One package with My Vendor assigned. - One package without a vendor. 3.) Filter the package results list by My Vendor. --> List is filtered to one package 4.) Leave the page, for example by navigating to Agreements. Return to the Packages list and you will see the issue (See also attached Screenshot) Actual result: The package results list becomes unresponsive / hangs after returning to the page. Expected result: The package results list should load and display the filtered results correctly. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 42928] New: In viewlog.tt #actionRETURN should be Retrun, not Check-in
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42928 Bug ID: 42928 Summary: In viewlog.tt #actionRETURN should be Retrun, not Check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 42131 updated the terminology in the table. We should also update the label for the #actionRETURN checkbox to be "Retrun". -- You are receiving this mail because: You are watching all bug changes.

1 20

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

13 Aug '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 18

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

13 Aug '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 16

[Bug 41988] New: OPAC: News RSS links with HTML not working
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41988 Bug ID: 41988 Summary: OPAC: News RSS links with HTML not working Initiative type: --- Sponsorship --- status: 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 The news RSS link on the OPAC appears to be invalid when the news content contains HTML. Users cannot subscribe to the feed using standard RSS readers or email clients. To reproduce: 1- Open the OPAC: https://princeville-test.styx.inlibro.net/cgi-bin/koha/opac-main.pl 2- Go to Tools -> HTML customizations -> News 3- Click New Entry with the following settings: 3-1- Display location: OPAC 3-2- Publication date: today 3-3- Title: "News test" 3-4- Content: click on <> and paste some HTML code, for example: <span style="color: #ba372a; font-size: 12pt;">Le Prêt entre bibliothèques est mis en pause. Désolés de l'inconvénients.<br />Merci de votre compréhension.</span> 4- Save the entry. 5- Go to the OPAC and copy the "RSS feed for system-wide library news" link. 6- Execute: curl -v http://opac/cgi-bin/koha/opac-news-rss.pl?branchcode= and copy the XML output to https://validator.w3.org/feed/ to check the feed. ==> The feed is not valid. 7- Try to create a subscription to this link in an email client (e.g., Thunderbird). ==> It does not work, giving the error "Feed URL is not valid". -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 40492] New: Pending offline circulation actions - barcode link should link to item details
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40492 Bug ID: 40492 Summary: Pending offline circulation actions - barcode link should link to item details Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In the pending offline circulation actions table, the barcode links to the biblio record, but it would be more helpful if it linked to the item details of the specific item. -- You are receiving this mail because: You are watching all bug changes.

1 23

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

13 Aug '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 38

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

13 Aug '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 48