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

[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

[Bug 42714] New: Koha::Script should automatically log start and end of scripts when they are run
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42714 Bug ID: 42714 Summary: Koha::Script should automatically log start and end of scripts when they are run Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Currently, our scripts/cronjobs are expected to add cronlogaction calls at the start and end to ensure they are recorded in the action logs. This is tricky as we have to maintain these lines in all cron scripts An easier way to do this is to add INIT and END blocks to Koha::Script - these can log the run, and require only one line per file to add the logging. Adding to Koha::Script will mean that any command line script using it will be recorded, but I think this is actually a benefit and makes tracing actions easier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 34962] New: Add a system messages feature to Koha to report issues and failures in a more visible way
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34962 Bug ID: 34962 Summary: Add a system messages feature to Koha to report issues and failures in a more visible way Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Many web projects have a "system messages" area to report cron failures and things like that. These messages are often dismissable. I think it would be great to have a "system messages" table that we could insert things into to make staff aware that something has failed. What I'm imagining is something like wrapping cronjob code in a try/catch and reporting cronjob failures. This would dovetail with action logs. Action logs lot you got searching for issues. This would put the issue right in front of you and would be trigger by actual failures. It could be used to report records with malformed MARC. It could be used to report items that are missing a required field that Koha assumes exists to function, and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 43295] New: Add ability to report external authentication service failures when falling back to local auth
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43295 Bug ID: 43295 Summary: Add ability to report external authentication service failures when falling back to local auth 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When an authentication service is down ( say LDAP ), Koha will fall back to local authentication. The only indicator of this happening are slow login times. It would be good to store these failures as errors somewhere in the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1