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

[Bug 36909] New: Eliminate duplicate ID in cookie consent markup
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36909 Bug ID: 36909 Summary: Eliminate duplicate ID in cookie consent markup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 27378 The HTML validator complains about duplicate IDs in the cookie consent markup: One div#consentButtons in the header, one in the footer. These can be updated to be classes instead. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27378 [Bug 27378] Enable compliance with EU Cookie Legislation via cookie consent -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 37002] New: Correct several HTML markup errors
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37002 Bug ID: 37002 Summary: Correct several HTML markup errors Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 33195 There are several HTML markup errors reported by the W3C validator when looking at the source of the bibliographic detail page in the staff interface. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33195 [Bug 33195] Reindent the bibliographic details page -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 36966] New: Fix links for local cover images for items on staff detail page
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36966 Bug ID: 36966 Summary: Fix links for local cover images for items on staff detail page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The links for local cover images aren't built correctly on the detail page of the staff interface While it doesn't cause a problem on current "main", any development that sets the "item" variable in the template at a higher level will generate fatal errors. Owen has bumped into this in his Bootstrap 5 work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 36672] New: Circulation rules are performing too many lookups
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36672 Bug ID: 36672 Summary: Circulation rules are performing too many lookups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com See bug 36668 - it tackles the size of the circulation page but doesn't significantly increase load time. Profiling it seems we spend about 50% of the loading time on Koha::Template::Plugin::CirculationRules::Search Looking at the template, for every section after the main rules block we loop over categories or itemtypes, and lookup the value for each rule name. In systems with large numbers of categories and item types this becomes very slow. In the rules section, we have already built a hash of rules by category and itemtype - we should continue to use this throughout the page. Additionally, we don't need to use all category/item types, we can use the 'used_categories' array from bug 36447 to only attempt categories that we know have rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 36785] New: opac-tags: Resolve warning about unrecognized biblionumber
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36785 Bug ID: 36785 Summary: opac-tags: Resolve warning about unrecognized biblionumber Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org The warning actually contains a typo: [2024/05/04 18:07:29] [WARN] get_approval_rows received unreconized argument key 'biblionumber'. at /usr/share/koha/opac/opac-tags.pl line 336. Where does it come from? Apparently by adding a biblionumber to the URL parameters. opac-tags does silently seem to ignore it. Note that you can see the tags on a specific biblionumber on opac-detail. Small fix coming. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 36797] New: Record with 1000+ holds and unique priorities causes a 500 error
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36797 Bug ID: 36797 Summary: Record with 1000+ holds and unique priorities causes a 500 error Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 To recreate: 1. Find a record that has 1000 non-waiting holds with different priorities. 2. Try loading the reserve page for that record ( /reserve/request.pl?biblionumber=X ) 4. Error: Template process failed: undef error - WHILE loop terminated (> 1000 iterations) This looks to be because of TT 'While' loop in holds_table.inc: [% BLOCK priority_dropdown %] [%- SET loop_priority = 1 -%] [%- WHILE loop_priority <= last_priority -%] [%- IF this_priority == loop_priority -%] <option value="[% loop_priority | html %]" selected="selected">[% loop_priority | html %]</option> [%- ELSE -%] <option value="[% loop_priority | html %]">[% loop_priority | html %]</option> [%- END -%] [%- loop_priority = loop_priority + 1- %] [%- END -%] [% END %] TT documentation states that it will terminate a WHILE loop larger than 1000 to prevent runaways: https://template-toolkit.org/docs/manual/Directives.html#section_WHILE -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 35559] New: Can't change the pickup date of holds on the last day of expiration
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35559 Bug ID: 35559 Summary: Can't change the pickup date of holds on the last day of expiration Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Our libraries complained that the expiration date of holds awaiting pickup can no longer be changed on the last day of the pick-up period. In the previous version, it was possible. To reproduce the problem: 1) Create or use existing hold that is awaiting pickup. 2) Set it's expiration date to today. 3) Check that you can't change the expiration date anymore as it says "Expired: %date%" -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 36482] New: Make it possible to embed desks and cash_registers on /libraries
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36482 Bug ID: 36482 Summary: Make it possible to embed desks and cash_registers on /libraries Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 36495] New: Add resource_not_found() and resource_deleted() helpers
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36495 Bug ID: 36495 Summary: Add resource_not_found() and resource_deleted() helpers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com In order to get consistent in our response structures I propose to introduce a couple Mojolicious helpers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 18885] New: Onsite Checkout has a weird behaviour concerning sticky due date
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18885 Bug ID: 18885 Summary: Onsite Checkout has a weird behaviour concerning sticky due date Change sponsored?: --- Product: Koha Version: master 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.m.hall(a)gmail.com When you perform an onsite checkout, the next checkout is pre-setted as follows: - Specify due date => today - Onsite checkout => not checked I don't think this is is a correct behaviour: according to me there are 3 solutions, but I don't know which is the best: - Maintaining "onsite checkout" checked - Don't change duedatespec in interface when onsite checout is clicked and process it in the intranet part - Remove the duedatespec on the new checkout page loading This part of the code is really hard for me since it were patched and re patched and I'm not sure of the expected behaviour of all lines, so I would like some expert opinion before coding a solution -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22