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

[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

[Bug 36239] New: Availability calculation in OPAC Results XSLT is too slow
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36239 Bug ID: 36239 Summary: Availability calculation in OPAC Results XSLT is too slow 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org buildKohaItemsNamespace is really slow in XSLTParse4Display when there is a record with a large number of items. On one system, we notice a search on the staff interface is 12 seconds whereas it's 1-2 minutes in the OPAC. I'm slowly tweaking things to improve the speed, but one of the big killers is buildKohaItemsNamespace. I think there are many use cases for having a Real Time Availability API endpoint, and this would be one of them. We could have a little loading CSS-driven graphic, send a list of biblionumbers to the endpoint asynchronously, and then render the availability. If we handle the availability through that endpoint (or at least a singular model method), we should be able to make further optimizations to availability calculation as well... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11808] When searching for a cardnumber in the intranet, also try to search for it on the LDAP server if one is configured and add/update user
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11808 Phan Tung Bui <phan-tung.bui(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #144826|0 |1 is obsolete| | --- Comment #20 from Phan Tung Bui <phan-tung.bui(a)inlibro.com> --- Created attachment 162857 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=162857&action=e… Bug 11808: Add the SearchCardnumberWithLDAP system preference Add option to search patrons on ldap server when not found in local database and import it Test plan: 0. You need to have an ldap server containing patron informations configured in Koha. 1. Apply patch and update database. 2. Check that the new system preference SearchCardnumberWithLDAP has been added and set as 'never'. 3. Choose a patron who exists in your ldap server but not in Koha. (you can delete an existing patron from Koha if needed) 4. Search for the patron by it's cardnumber in the following locations. Do not choose from the dropdown list, use the submit button. - circ/circulation.pl - circ/article-request.pl - reserve/request.pl - members/member.pl both at the top and in the filter box - any page using common/patron_search.tt, for example adding a guarantor with the members/guarantor_search.pl popup => Should return cardnumber/patron not found or no results 5. Change SearchCardnumberWithLDAP to 'if not found locally'. 6. Repeat step 4. => The patron should be added to Koha. 7. Edit the patron and change any of the existing information. 8. Repeat step 4. => The patron has not been updated (the change made in step 7 is still there) 9. Change SearchCardnumberWithLDAP to 'always'. 10. Repeat step 4. => The patron has been updated. Change made in step 7 has been rewritten and patron informations is the same as in step 6. 11. Try searching for a patron who doesn't exist in Koha and has a nonexistant branch on the LDAP server. An error message should appear accompanying the absence of results. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11808] When searching for a cardnumber in the intranet, also try to search for it on the LDAP server if one is configured and add/update user
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11808 Phan Tung Bui <phan-tung.bui(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |36260 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36260 [Bug 36260] Port default PROBLEM_REPORT notice to Template Toolkit syntax -- You are receiving this mail because: You are watching all bug changes.

1 0