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

[Bug 30673] New: Improve is_valid_date function for validating date strings
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30673 Bug ID: 30673 Summary: Improve is_valid_date function for validating date strings Change sponsored?: --- Product: Koha Version: master 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 The is_valid_date() function in calendar.js has two jobs: Confirm that the date string matches the current date format according to a regular expression; and confirm that the date is an actual date. Both must be true. For example: "2002-03-14" matches the date format "Y-m-d" and is a valid date -- valid date. "03/14/2002" doesn't match the date format "Y-m-d" even though it is a valid date -- invalid date. "38-44-2103" doesn't match the date format "Y-m-d" and isn't a valid date -- invalid date. is_valid_date() needs some changes in order for it to correctly handle custom date formats being specified which override the default date format (from the system preference). It also needs a new way to check that a date string represents a valid date. The old jQueryUI method looks similar but behaves differently. $.datepicker.parseDate() would throw an exception if the date were invalid. flatpickr.parseDate() will try to interpret an invalid date as if it were valid. For example: flatpickr.parseDate("2002-48-66", "Y-m-d") -> Date Sat Feb 04 2006 00:00:00 flatpickr.parseDate("2002-48-66", "m/d/Y") -> Date Mon Aug 02 2027 00:00:00 -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 30836] New: Elasticsearch mappings.yaml is out of sync with upgraded databases
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30836 Bug ID: 30836 Summary: Elasticsearch mappings.yaml is out of sync with upgraded databases Change sponsored?: --- Product: Koha Version: unspecified 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We discovered on IRC today that the mappings.yaml default mappings for ES indexing has fallen out of sync with upgraded databases.. We need to create a DB update for each mappings change and we haven't been doing so. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 21092] New: Bad template in patron card creator can cause server issues
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '22

08 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21092 Bug ID: 21092 Summary: Bad template in patron card creator can cause server issues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org While creating the PDF file for a patron card batch the CPU goes to 100% and brings the server down. We have seen this behaviour in 2 separate package installations running 17.11.07 so far. We have sadly not been able to make it happen in a dev environment. Filing the report in hope that someone has an idea or seen something similar that will help us to nail down the problem. So far we think the problem is related to 0 values in a patron card template. I will attach screenshots of the layout and patron card template used, when the problem appears. To test: - Add patron card template - Add patron card layout (or use existing) - Create batch of patrons - Export - Click on PDF link - Boom! There is no error, the system just keeps loading. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 28371] New: Improve performance of XSLTParse4Display
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '22

08 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28371 Bug ID: 28371 Summary: Improve performance of XSLTParse4Display 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This routine is quite slow, and heavy on DB lookups -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 30756] New: Get skip block out of Koha_Authority.t and add TestBuilder
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '22

08 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30756 Bug ID: 30756 Summary: Get skip block out of Koha_Authority.t and add TestBuilder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org This test contains 3 skips on Jenkins. It uses a MARC file. We could quite easily resolve this with TestBuilder. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 20416] New: Remove hide_marc and advancedMARCeditor system preferences
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '22

08 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20416 Bug ID: 20416 Summary: Remove hide_marc and advancedMARCeditor system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl These two system preferences allow small customizations of the cataloging interface, namely showing only labels, or only the numbers. I don't think it's any use, almost everyone has the same values according to hea, and i am pretty sure the few libraries who don't can deal with seeing a framework with tag numbers and labels. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 23190] New: Authority hierarchy display appears to be broken
by bugzilla-daemon＠bugs.koha-community.org 08 Aug '22

08 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23190 Bug ID: 23190 Summary: Authority hierarchy display appears to be broken 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- We followed the instructions on bug 8523 comment 19, but we didn't manage to get a tree view: AuthDisplayHieararchy ON Example: 151 $aGermany 551 $a Baden-Württemberg $w h 151 $aBaden-Württemberg 551 $a Konstanz $w h 551 $a Germany $w g 151 $aKonstanz 551 $a Baden-Württemberg $w g 551 $a Fürstenberg $w h 551 $a Paradies $w h 151 $a Fürstenberg 551 $a Konstanz $w g 151 $a Paradies 551 $a Konstanz $w g The authority that is displayed shows as the only entry of the 'tree' abvove the record in staff and OPAC. Links have been cataloged in both directions. Screenshots from Owen on bug 21128 from 2018 suggest that the feature still worked at this time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 26370] New: Add ability to disable demagnitizing items via SIP2 for arbitrary patron categories
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '22

05 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26370 Bug ID: 26370 Summary: Add ability to disable demagnitizing items via SIP2 for arbitrary patron categories Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 23625] New: ArticleRequestsMandatoryFields* only affects field labels, does not make inputs required
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '22

05 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23625 Bug ID: 23625 Summary: ArticleRequestsMandatoryFields* only affects field labels, does not make inputs required Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org Steps to recreate: 1) Enable article requests ( syspref: ArticleRequests => Enable, Circ and fine rules ALL/ALL (or a given category/itemtype): Article requests => Yes ) 2) Set one or more fields to require in the ArticleRequestsMandatoryFields, ArticleRequestsMandatoryFieldsItemOnly, and/or ArticleRequestsMandatoryFieldsRecordOnly settings (all these settings are affected in the same manner) 3) Search for a title and select the "Request Article" button from the OPAC search results 4) Authenticate as a patron 5) Neglect to fill out at least one of the mandatory fields (their <label>s will have a "required" class making them appear red in the default theme) 6) Select the "Place Request" button at the bottom of the form 7) The form should not submit without the required fields but it does anyways. The basic issue is that the opac-request-article.tt template https://github.com/Koha-Community/Koha/blob/master/koha-tmpl/opac-tmpl/boot… creates the same non-required <input> elements regardless of whether a field is required or not. Here is one example: <li> [% IF mandatory_fields.search('title') %] <label for="title" class="required">Title:</label> [% ELSE %] <label for="title">Title:</label> [% END %] <input type="text" name="title" id="title" size="50"/> </li> I believe that all of the form fields should be modified such that both the <label> AND <input> are different depending on whether a field is required or not: <li> [% IF mandatory_fields.search('title') %] <label for="title" class="required">Title:</label> <input type="text" required name="title" id="title" size="50"/> [% ELSE %] <label for="title">Title:</label> <input type="text" name="title" id="title" size="50"/> [% END %] </li> -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 27947] New: Add cancellation reasons to article requests
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '22

04 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27947 Bug ID: 27947 Summary: Add cancellation reasons to article requests 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Similar to holds we propose to add an authorised value list of 'reasons' for cancellation of article requests -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 106