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

[Bug 37161] New: After deleting a tag in a MARC framework, template doesn't do the [% IF ( delete_confirmed ) %] stuff
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37161 Bug ID: 37161 Summary: After deleting a tag in a MARC framework, template doesn't do the [% IF ( delete_confirmed ) %] stuff 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: emily.lamancusa(a)montgomerycountymd.gov In older versions (I tested in 23.05.11 since I had it handy), when you edit a MARC framework and delete a tag, you get a page saying "Tag deleted" with an OK button, and clicking the button reloads the framework you were in (though not exactly the way it was originally inteded to, since it's supposed to reload with a search for the tagnumber, so you wind up in the same place you were). In main, you don't get the "Tag deleted", which is inside an [% IF ( delete_confirmed ) %]. I don't see what magic was ever setting delete_confirmed, unless it was set by that being the name of the $op back before it became cud-delete_confirmed. https://git.koha-community.org/Koha-community/Koha/src/commit/582d6916c9a4e… explicitly sets it, but I don't see where anything else does, and if the magic was coming from the $op, then there's a whole bunch more things that need to be fixed to set it. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 37127] New: Authorized value select not working on authority forms.
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37127 Bug ID: 37127 Summary: Authorized value select not working on authority forms. Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When connecting an authorized value on a subfield on Authority Type framework configuration (Example: 040$b - Authorized value: LANG) the Select widget (Select2?) on the cataloging form (Edit/New) is not working. This seems to happen for any connection on any authorized values/subfields only on authorities cataloging. Tried creating new authorized value category etc, but the behavior is the same. Thanks -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[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