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

[Bug 42004] New: Checkout history becomes weird after 1000 checkouts on an item
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42004 Bug ID: 42004 Summary: Checkout history becomes weird after 1000 checkouts on an item Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com This code from issuehistory.pl looks very weird to me, in particular when you have a timestamp ordered ascendently. A temporary fix waiting for an update of the array would be to order by timestamps descending. 51 my @old_checkouts = Koha::Old::Checkouts->search( 52 { biblionumber => $biblionumber }, 53 { 54 join => 'item', 55 order_by => 'timestamp', 56 rows => 1000, 57 } 58 )->as_list; Steps to reproduce : 1 - Add 1000+ checkouts 2 - visit issuehistory.pl -> the last issues are not on top. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 39894] New: Bookings not also correctly set to the beginning or end of each day
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39894 Bug ID: 39894 Summary: Bookings not also correctly set to the beginning or end of each day Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I had some trouble recreating this one but here goes: To recreate: 1. In your koha-conf.xml set the timezone to: <timezone></timezone> 2. Enable bookings and make an item or itemtype bookable. 3. Place a booking and have a look at the start_date and end_date in the DB: select start_date, end_date from bookings; 4. This might look something like: 2025-05-13 02:00:00 | 2025-05-15 01:59:59 So depending on your timezone and time of day the booking end_date might creep into the next day which causes confusion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 15261] Verify if checkout or hold request periods overlap with existing holds
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 --- Comment #127 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- In C4/Reserves.pm : + RevertWaitingStatus Looks like this method has be moved by Bug 40058 There is no call in patches so I think we can just remove this line. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33430] New: Suggestions.pl with several hundred items causes a slow loading screen
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33430 Bug ID: 33430 Summary: Suggestions.pl with several hundred items causes a slow loading screen Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The purchase suggestion management page take anywhere between 15-45 seconds to load if there are several hundred items in the suggestions table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 117

[Bug 38689] New: EDIfact errors should log to a staff accessible location
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38689 Bug ID: 38689 Summary: EDIfact errors should log to a staff accessible location Change sponsored?: --- 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 38423 We currently log a lot of detail using the editrace log, but it all goes onto server side only files. We should do similar to what we do for email delivery failures and log to a table and display user friendly errors in the UI so that end users are a) aware of such issues and b) may be able to resolve such issue's by updating their config and/or mappings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38423 [Bug 38423] EDIFACT invoice files should skip orders that cannot be receipted rather than failing to complete -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 128

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #268 from Lari Taskula <lari.taskula(a)hypernova.fi> --- (In reply to Jonathan Druart from comment #266) > Patch application failed for attachment 194449 [details] [review] - Bug > 38365: Make swagger-cli happy > > > failed: error: sha1 information is lacking or useless > (api/v1/swagger/definitions/csp_report.yaml). Hmm all patches apply cleanly for me, using git-bz. On top of c3cf41c275695d260c5397e7cfbd4cf83e60fa9c -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #267 from Jonathan Druart <jonathan.druart(a)gmail.com> --- (In reply to Jonathan Druart from comment #265) > (In reply to David Cook from comment #258) > > (In reply to Jonathan Druart from comment #253) > > > And those ones when testing the UI: > > > * cataloguing/value_builder/* (oops, all cataloguing plugins are broken) > > > We might need to adjust the xt test and add_csp_nonces.pl to caught those > > > files as well. > > > > So these aren't actually broken. When I was first working on the patches, I > > thought they would be, but the script tags are actually already re-written > > by Koha/FrameworkPlugin.pm, so it adds the nonce to them. If you try out the > > cataloguing plugins, they should all work without any violation reports. See > > the patch labelled "Bug 38365: Fix nonce caching and add to framework plugin > > scripts". > > I do see dozens of violations in the console when I edit a biblio: > https://snipboard.io/X7OYJp.jpg I cannot clone a subfield. And plugins don't work (tried with 100$a) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Patch doesn't apply --- Comment #266 from Jonathan Druart <jonathan.druart(a)gmail.com> --- Patch application failed for attachment 194449 - Bug 38365: Make swagger-cli happy failed: error: sha1 information is lacking or useless (api/v1/swagger/definitions/csp_report.yaml). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #265 from Jonathan Druart <jonathan.druart(a)gmail.com> --- (In reply to David Cook from comment #258) > (In reply to Jonathan Druart from comment #253) > > > > 7. When enabled, I see an error in the browser's console: > > > > Content-Security-Policy: The page’s settings blocked the loading of a > > > > resource (media-src) at data: because it violates the following directive: > > > > “default-src 'self'” > > > > > > That's interesting. I'd like to hear more about this one. Were there > > > additional details? I wonder if it had to do with audio when doing a > > > checkout or something? > > > > No idea! There is nothing else! Don't you see it? > > Nope! I haven't been able to find it. I don't see it anywhere. Does it > happen on a particular page? All pages: https://snipboard.io/if28Qu.jpg > > Ok, however I found more: > > Caught by the xt tests (and now by add_csp_nonces.pl as well) > > * t/lib/plugins/Koha/Plugin/TestValuebuilder/test_valuebuilder_popup.tt > > So this is an interesting one. I will upload a patch for this one, but it's > going to work differently to what you might expect. I'll explain more in my > response to your comment about cataloguing plugins. > > (To test this one, you'll want to run `prove > t/db_dependent/Koha/Plugins/Valuebuilder_hooks.t`) xt/find-missing-nonce.t is still failing on this file then. Should we exclude it? > > And those ones when testing the UI: > > * cataloguing/value_builder/* (oops, all cataloguing plugins are broken) > > We might need to adjust the xt test and add_csp_nonces.pl to caught those > > files as well. > > So these aren't actually broken. When I was first working on the patches, I > thought they would be, but the script tags are actually already re-written > by Koha/FrameworkPlugin.pm, so it adds the nonce to them. If you try out the > cataloguing plugins, they should all work without any violation reports. See > the patch labelled "Bug 38365: Fix nonce caching and add to framework plugin > scripts". I do see dozens of violations in the console when I edit a biblio: https://snipboard.io/X7OYJp.jpg > I think an argument could be made for fixing them a different way... and you > just reminded me of why I used an ENV variable initially. It was for this. > When the plugins get launched the CGI context gets re-set which is why I > lost the cached values, but the ENV variable would persist and the package > level variable are fine. > > > Also wondering if this one won't require adjustment: > > misc/devel/tidy.pl:172 $content =~ s#\n*( > > *)<script>\n*#\n$1<script>\n#g; > > Yeah I guess so since it won't match. I've written a patch that will cover > this (as well as a future where we have other attributes like type for ESM > modules or use async or defer). Hum I've revert your patch and tried to see how it broke the tidy but it didn't. All good but maybe this is no longer needed. Will keep in mind if some tidy errors appear in the next weeks. > > > > 10. Vue apps have styling issues: > > > > Content-Security-Policy: The page’s settings blocked an inline style > > > > (style-src-elem) from being applied because it violates the following > > > > directive: “style-src 'self' 'nonce-UrNLygw_Cc1zaPU2WH0qVk'”. Consider using > > > > a hash ('sha256-t4I2teZN5ZH+VM+XOiWlaPbsjQHe+k9d6viXPpKpNWA=', requires > > > > 'unsafe-hashes' for style attributes) or a nonce. > > > > It's coming from insertBySelector.js and styleTagTransform.js > > > > > > I have been wondering if the Vue apps would have trouble. > > > > > > According to https://webpack.js.org/loaders/style-loader/#nonce, > > > style-loader isn't recommended for production. Note the security warning on > > > https://www.npmjs.com/package/style-loader as well. How does style-loader > > > get used in Vue currently? > > > > Looks like it is used to load all the inline style tags. > > > > Todo - Vue apps are broken. > > Todo - Adjust xt test to parse .vue files(?) > > Since style-loader isn't recommended for prod use, I think we look at > replacing that. It looks like "mini-css-extract-plugin" is typically what's > used which will put the CSS into a separate file. > > Note that nothing is broken per se. We're not turning on CSP by default, and > you can always override the default CSP to allow inline styles if you want. > So we have time to work out some of these changes while still forging ahead. > > I see what you mean though. If I turn on ERM and go to > http://localhost:8081/cgi-bin/koha/erm/home I see a lot of inline style > violations. > > Alternatively, I think that style-loader might have support for > __webpack_nonce__ . I need to have a very late lunch but I'll check that out > too... Nice one! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40021] New: Koha/Plugins/Recall_hooks.t produces warnings
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40021 Bug ID: 40021 Summary: Koha/Plugins/Recall_hooks.t produces warnings Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 25515 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25515 [Bug 25515] [OMNIBUS] Remove warnings and errors from tests output -- You are receiving this mail because: You are watching all bug changes.

1 16