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

[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 24879] Add missing authentication checks
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24879 Wainui Witika-Park <wainuiwitikapark(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Pushed to oldoldoldstable |RESOLVED -- You are receiving this mail because: You are watching all bug changes.

1 0

[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

[Bug 38788] New: Fix '0000-00-00' issue on database
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38788 Bug ID: 38788 Summary: Fix '0000-00-00' issue on database Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: adifbbk1(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Continuation of the thread from https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31143#c90 I have mysql version 8.0.40-0ubuntu0.24.04.1 setup in the remote azure machine. The infrastructure is setup such that there are 2 VMs, one acting as Koha application server and another acting as MySQL database server. MySQL server does not have koha installed but the credentials are setup such that application server has access to it. I am getting errors while running fix_invalid_dates.pl file. DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Incorrect TIMESTAMP value: '0000-00-00' at ./fix_invalid_dates.pl line 65 The line 65 contains this line: my $invalid_dates = $rs->search( { $column => '0000-00-00' } )->count; It is very obvious that the mysql database throws sanity errors when there are errors in database. To attempt fixing it, I added these lines on top: # Disable strict mode for this session $schema->storage->dbh_do( sub { my ($storage, $dbh) = @_; $dbh->do("SET SESSION sql_mode = ''"); # Disables all kinds of checks in mysql for the whole script session } ); These seemingly did nothing. After running cli tool, it didn't return any response. Especially when I try searching names of old patrons, it throws error "month out of range" (there is possibility that the "borrowers" table is not properly cleaned using that script) What worked for me is below command when running mysql as root user: UPDATE borrowers SET lastseen = NULL WHERE CAST(lastseen AS CHAR) = '0000-00-00 00:00:00'; -- 6000+ rows changed UPDATE borrowers SET date_renewed = NULL WHERE CAST(date_renewed AS CHAR) = '0000-00-00'; -- 3000+ rows changed UPDATE categories SET enrolmentperioddate = NULL WHERE CAST(enrolmentperioddate AS CHAR) = '0000-00-00'; -- 4 rows changed Please suggest me if there are other tables having same issue too so that I can manually fix it using mysql. I manually created and run the fix_invalid_dates.pl file using koha-shell in koha 23.11 (which was originally not backported) but I don't think the script file not working properly is version-related issue at all. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4