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

[Bug 36367] New: Remove context stack
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36367 Bug ID: 36367 Summary: Remove context stack Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It's not used and is confusing. It does not make sense for now with plack and our current codebase. We should remove it (and the other places using this pattern) and reintroduce it later, correctly implemented, if we need it back. -- You are receiving this mail because: You are watching all bug changes.

1 47

[Bug 38357] New: When adding new holidays Koha sometimes copies same holidays to other librarys
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38357 Bug ID: 38357 Summary: When adding new holidays Koha sometimes copies same holidays to other librarys Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal 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 173980 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173980&action=e… Holidays module (calendar) I noticed that when I add unique holiday to a library and repeat adding different holidays to two other librarys, the third library will have random unique holidays even if it should't have. It's easier to explain with pictures so I put them in an PDF and added it as an attachment. But here's what I did: 1. I added one week as unique holidays to Tyrnava library from 2025.03.03.to 2025.03.09. All went well. 2. I added one week as unique holidays to Tupos library from 2025.03.10 to 2025.03.16. All went well. 3. I added one week as unique holidays to Tuira library from 2025.03.17 to 2025.03.23. This didin't go so well: Tuira had unique holidays two weeks, but I added only one week. 4. I added one week as unique holidays to Temmes library from 2025.03.03 to 2025.03.09. This didin't go so well either: After saving Temmes had unique holidays three weeks, but I added only one week. 5. I added one week as unique holidays to Taivalkoski library from 2025.03.24 to 2025.03.30. This time after saving Taivalkoski's holidays, library had unique holidays two weeks (in the beginning of March and in the end of March), but I added only one week. These above are easy to fix because you see them at once, but we had also unique holidays that appeared on the other months (for example christmas-holidays appeared to librarys that are open on christmastime and don't need holiday-markings on their calendar.) so those extra-holidays could be hard to catch. We don't have this problem in Koha version 23.11, but in the version 24.05 it is going to be a problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 37656] New: Advanced editor needs to HTML-escape Z39.50 search results
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37656 Bug ID: 37656 Summary: Advanced editor needs to HTML-escape Z39.50 search results Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Noticed because for some reason OCLC records cataloged in German for English works have a leading article in the title surrounded by << >>, which in the advanced editor's Z39.50 search results appear as "< > Title" for a record with "<<The>> Title" and for <<A>> Title the word Title appears as a link. Steps to reproduce: 1. Set EnableAdvancedCatalogingEditor to Enable 2. Edit any bib record, paste <script>alert('boo ❤')</script> at the end of 245‡a and save 3. Below the search fields in the left sidebar, click Advanced » 4. Check the checkbox for Local catalog, uncheck any others that are checked, and search for anything that will return the record you altered. 5. Get an alert() from Z30.50 search results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 37655] New: Basic editor needs to HTML-escape the bib record title used as a heading
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37655 Bug ID: 37655 Summary: Basic editor needs to HTML-escape the bib record title used as a heading Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When you edit an existing record, the basic editor has an <h1> at the top of the page saying "Editing {bib title} (Record nnn)", which fails to HTML-escape the title. That gives you unpleasant results if the title is something like "<h2> is a second-level heading" making the entire editor an <h2>, or it gives you alarming results if someone has stuck a <script> in the title. Steps to reproduce: 1. Edit any bib record, stick <script>alert('boo ❤')</script><h2> at the end of the title in field 245 subfield a 2. Save, then edit the bib record again. 3. Oops, that alert() could have been more serious. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 37654] New: Batch record import needs to HTML-escape the Citation column
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37654 Bug ID: 37654 Summary: Batch record import needs to HTML-escape the Citation column Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 170412 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170412&action=e… Sample record for HTML escaping After you stage a batch of records for import, they are displayed with a Citation column which contains the title and author. Those need to be HTML-escaped, both so that things like < will display correctly and so that your compromised vendor won't deliver a batch of XSS to you. Steps to reproduce: 1. Download the attached "Sample record for HTML escaping" 2. Cataloging - Stage records for import - Select the downloaded file - Upload file - Stage for import 3. When the background job completes, View batch - get an alert() from the bib title, note that the author name "Person" is a link. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 36331] New: Items that cannot be held are prevented renewal when there are holds on the record
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36331 Bug ID: 36331 Summary: Items that cannot be held are prevented renewal when there are holds on the record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the case where an item cannot be held 'AllowRenewalIfOtherItemsAvailable' will deny renewal if no other items are available. Since the holds don't affect this item, it is invalid. There is a FIXME in the code about this: # FIXME: We are not checking whether the item we are renewing can fill the hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 36511] New: Local cover images in admin interface after update
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36511 Bug ID: 36511 Summary: Local cover images in admin interface after update Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: isabel.pineda(a)ds.edu.sv QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Today I updated Koha from version 23.11.03 to 23.11.04 and now the local cover images of the books are not visible anymore in the admin interface. In the OPAC they are still visible normally. When I upload a new local cover image, I can see it in the OPAC interface too, but not in the admin interface. Is there some error in the update? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 36047] New: Apostrophe in suggestion status reason blocks order receipt
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36047 Bug ID: 36047 Summary: Apostrophe in suggestion status reason blocks order receipt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org Since the new way of receiving orders in 23.11, the receiving of an order is impossible when this order was created from a purchase suggestion and the reason for accepting the suggestion contains an apostrophe. I didn't test all possible characters. Exclamation and question marks, comma's and semicolons all seem fine. Temporary workaround is to edit the suggestion were the order came from and remove the apostrophe. However, by editing the suggestion, the patron who made the suggestion will get another automatic notice that the title has been ordered and the library will get another email that a suggestion was made, so not ideal. And it slows down the acquisition process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 39007] New: Add last_audit to the sushi_service API spec
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39007 Bug ID: 39007 Summary: Add last_audit to the sushi_service API spec Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org A new field has been added to the response object for the sushi service API, this needs updating in our specs -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 31143] New: We should attempt to fix/identify all cases where '0000-00-00' may still remain in the database
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31143 Bug ID: 31143 Summary: We should attempt to fix/identify all cases where '0000-00-00' may still remain in the database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org With the move to more and more of Koha using the REST API's and our rest API's being suitably strict about date formats, we need to retrospectively correct occurrences of 0000-00-00 dates appear in database fields system wide. I've had enough occurrences of bad data still in the database after a number of upgrade and it biting me in the UI that I think we should now look at introducing a script to either bulk fix these or at the least identify them and warn they will cause serious issues going forward. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 127