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

[Bug 36133] New: 414 Request-URI Too Long when submitting lots of items for batch item modification from a biblio detail page
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36133 Bug ID: 36133 Summary: 414 Request-URI Too Long when submitting lots of items for batch item modification from a biblio detail page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We have a record with over 500 items attached. When we do select all> modify selected items, the browser serves an Apache 414 error: Request-URI Too Long The requested URL's length exceeds the capacity limit for this server. Apache/2.4.56 (Debian) Server at library.niwa.co.nz Port 443 This is because all of the itemnumbers get appended to the URL. We can still export the barcodes and go to Cataloging > Batch item modification and submit the barcodes that way, but it adds a few extra steps, and the error isn't great! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 31510] New: The notice template tag helper still uses <<>> sytnax.. we should move to TT instead
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31510 Bug ID: 31510 Summary: The notice template tag helper still uses <<>> sytnax.. we should move to TT instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The notice template param select list when working on a notice template still inserts a <<>> syntax replacement variable.. we should start using [% %] instead to encourage the adoption of TT more widely. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|36245 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36245 [Bug 36245] ILL - Custom backend form action is broken -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36245 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36245 [Bug 36245] ILL - Custom backend form action is broken -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|36245 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36245 [Bug 36245] ILL - Custom backend form action is broken -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36266] New: "Edit search" and "Search in result list" not working well together
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36266 Bug ID: 36266 Summary: "Edit search" and "Search in result list" not working well together Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It looks like that when you use the "search in results" feature, the "edit search" fails at least in some cases, as the created search is not the same. Example (works with ktd sample data) * In the staff interface, go to advanced search * Search for: Subject, phrase: biography * You should have 22 results * Enter "music" in the "Search within results" search box on top of the results list * You should have 3 results /cgi-bin/koha/catalogue/search.pl?idx=su%2Cphr&q=biography&&&limit=music * Click "Edit this search" link on top of results list * Verify both criteria show up in the form (the music one is at the bottom) * Don't change the form, just search again * NOT OK: 0 results /cgi-bin/koha/catalogue/search.pl?advsearch=1&idx=su%2Cphr&q=biography&limit=music%3A&other_music0=on&sort_by=relevance -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35941] OPAC user can guess clubs of other users
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35941 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldoldstable |Pushed to oldoldoldstable -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35941] OPAC user can guess clubs of other users
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

1 0

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|36249 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36249 [Bug 36249] ILL - "Request from partners" action is broken -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36264] New: XSLT processing is much slower on OPAC than Staff Interface
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36264 Bug ID: 36264 Summary: XSLT processing is much slower on OPAC than Staff Interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I haven't figured this one out yet, but it looks like the XSLT processing for search results is much slower on the OPAC than on the Staff Interface. No XSLT (disabled in code): OPAC: 18.69 seconds Staff: 10.5 seconds Default XSLT: OPAC: 25.7 seconds Staff: 10.6 seconds As you can see here, the XSLT processing for the staff interface is much faster. I’d say the OPAC takes 7 seconds whereas the Staff takes .1 seconds. This is certainly worth reviewing. (Note I'm using Zebra but it should be irrelevant for this testing. The same problem should exist for both Zebra and Elasticsearch...) (Note also that it's clearly not the only discrepancy between the two search interfaces. Note that OpacHiddenItems isn't contributing to the slowness on the OPAC side.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2