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

[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 25267] New: OPAC Browse Shelf feature is not responsive
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25267 Bug ID: 25267 Summary: OPAC Browse Shelf feature is not responsive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the OPAC the browse shelf feature is not responsive. To recreate: 1. Turn on OPACShelfBrowser. 2. If youre using test data you will have to give some items call numbers. I did: update items set itemcallnumber = 'acallnumber'; 3. It will also be best if you add some cover images. 4. Go to an item detail page and Browse Shelf. 5. The feature looks good until the viewport is about 1700px or less. -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 42440] New: Remove event attributes from labeled MARC detail template
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42440 Bug ID: 42440 Summary: Remove event attributes from labeled MARC detail template Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 38407 catalogue/labeledMARCdetail.tt has an "onChange" event attribute which is redundant. There's already a version of that event handler in the JS block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38407 [Bug 38407] Eliminate event handler attributes in the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 38358] New: To date don't follow when you are editing holidays
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38358 Bug ID: 38358 Summary: To date don't follow when you are editing holidays Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org Created attachment 173981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173981&action=e… To date does not follow the From date and you must find the right date manually When you are editing holidays "To date"-calendar don't follow the "From date"-date. Instead "To date"-calendar offers you today's date/month and you must click calendar forward to the right date/month. It would be nice if it worked like this: "To date"-calendar follows the date you put in "From date"-box. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18