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

[Bug 37165] New: Can't edit frequencies due to stray cud- in modify op
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37165 Bug ID: 37165 Summary: Can't edit frequencies due to stray cud- in modify op Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Serials Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 36192 serials/subscription-frequencies.pl has two modify ops: a POST with cud-savemod changes the frequency, and a GET with modify loads the editing form, except that was changed to cud-modify when it shouldn't have been. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 37152] New: Delete-confirm should not start with 'cud-'
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Bug ID: 37152 Summary: Delete-confirm should not start with 'cud-' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 36192 There are a number of pages that use the op delete_confirm to display a confirmation page before deleting an object, followed by the op cud-delete_confirm*ed* to actually perform the delete operation. A few pages slipped through that are expecting an op of cud-delete_confirm, which should not start with 'cud-': - acqui/basket.pl and basket.tt - opac/opac-suggestions.pl and opac-suggestions.tt - admin/auth-tag-structure.pl - admin/categories.pl - admin/aqcontract.pl - admin/marctagstructure.pl None of these broke functionality for me when I tested them - the first two because at least the .pl and .tt files align, and I'm not sure why the last four didn't break. Either way, they should still be brought in line with the coding guideline. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 37190] New: form-submit.js data- attributes should use lowercase attribute names
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37190 Bug ID: 37190 Summary: form-submit.js data- attributes should use lowercase attribute names Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If I try to add a link as a form ( see Bug 36246 ) I cannot pass the data-confirmationMsg attribute with $('.submit-form-link').data(); This is because data attribute names always get read in lowercase. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 37267] New: Allow specifying a target in form-submit.js
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37267 Bug ID: 37267 Summary: Allow specifying a target in form-submit.js Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: nick(a)bywatersolutions.com Depends on: 36246 Blocks: 37192 form-submit.js neatly takes care of links that used to do a GET but now have to POST if they were targeting the current window, but links that were opening a new window/tab with target="_blank" can't. form-submit.js should look for data-targetwindow and set its value as the target attribute of the form. Inconveniently, Bootstrap 4 uses data-target as the CSS selector you are targeting, though Bootstrap 5 namespaces it as data-bs-target, so we shouldn't use data-target. And possibly while form-submit.js is still young enough to change, we should namespace all the things that are aimed at it rather than at the form it creates, data-fs-method, data-fs-action, and then we could use data-fs-target, and someone who needs to submit a form with an input awkwardly named either method or action could get away with it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36246 [Bug 36246] Have a centralized method for submitting a form via a link https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37192 [Bug 37192] Can't print label from the item editor -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 37371] New: Direct input of dates not working when editing dates manually
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37371 Bug ID: 37371 Summary: Direct input of dates not working when editing dates manually Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Find a any date picker in Koha, like DOB in the patron record. 2. Add a date, either manually or using the date picker. 3. Once there is a date like 07/15/2024 try to edit only part of the date, or the '15'. 4. The date easily becomes malformed. I searched for bugs related to this with Maskito. Unfortunatly I think the Maskito libray and feature needs to be removed. See Bug 33703 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 35907] New: Add ability to log all custom report runs with or without query
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35907 Bug ID: 35907 Summary: Add ability to log all custom report runs with or without query 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Because of the way Koha::Logger has been used to log to different categories based on the interface and caller, it can be extremely hard to log all of a particular log statement to one place. For custom report runs, the category is plack-intranet.C4::Reports::Guided when run from the web interface, cron.C4::Reports::Guided when run from runreport.pl, and plack-intranet.C4::Auth when run from svc/report. We should add a more standardized report run log, both with and without the full query, so that administrators can log all report runs to a centralized location. If an administrator were to need the "point of entry" for reports, it is easy to include via parameters in PatternLayout. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 37029] New: 'About Koha' button on staff side homepage seems out of place among application buttons
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37029 Bug ID: 37029 Summary: 'About Koha' button on staff side homepage seems out of place among application buttons Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.auld(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The 'About Koha' button links to very important community and version information, but it seems out of place among the buttons for applications used on a daily basis by staff users. Could it be moved to the top menu or to the bottom of every page where 'about' buttons/links are more commonly found in web interfaces/applications? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 37374] New: Place Hold button nonresponsive for club holds
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37374 Bug ID: 37374 Summary: Place Hold button nonresponsive for club holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To reproduce: - create a club - put 1 patron in your club - find a bib - Click Holds, then Clubs - search for your club, confirm hold detail - click Place Hold - nothing happens -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 26866] New: Items table on additem should sort by cn_sort
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26866 Bug ID: 26866 Summary: Items table on additem should sort by cn_sort Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: - create a bib - add three items with source of classification LCC, call numbers: -- JC43 .G6 1890 -- JC330 .F74 2000 -- JC480 .R63 2006 - on additem.pl, sort the items table by "Full call number" - notice items are order incorrectly, going 330, 43, 480 - use a report to pull the cn_sort values for your 3 items, confirm that ordering by cn_sort in your report correctly orders them 43, 330, 480 We should use cn_sort here to get them in the correct order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 37324] New: Self registration complete login form won't login user
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '24

10 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37324 Bug ID: 37324 Summary: Self registration complete login form won't login user Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org When using self registration in opac and filling out the requested fields you are forwarded to a login. Either this is prefilled or you can enter the credentials provided on the same site. When clicking login opac-user.pl opens showing a login form. The user we just created is not logged in. To recreate: a) open http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfie… b) set PatronSelfRegistration o allow c) set PatronSelfRegistrationDefaultCategory to Self registration d) logout or open a private tab e) http://localhost:8080/cgi-bin/koha/opac-memberentry.pl and enter required fields d) Registration complete! appears with a prefilled login form. Click Log in. e) Check you are not logged in -- You are receiving this mail because: You are watching all bug changes.

1 25