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

[Bug 30827] New: Autobarcode discards leading zero
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30827 Bug ID: 30827 Summary: Autobarcode discards leading zero Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you set autobarcode to "generated in the form 1,2,3," Koha will find the largest numeric barcode in your system and add 1. However, if your largest numeric barcode has leading zeros, those will not be maintained in your new item. So if the current highest barcode is "09000," the next barcode generated will be "9001." Apparently we fixed this on bug 5681 way back in 2011, but it has since regressed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 27426] New: Plugin barcode must keep leading zeros
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27426 Bug ID: 27426 Summary: Plugin barcode must keep leading zeros Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If autoBarcode is set to incremental, we are generating the next barcode adding 1, but casting to integer. If you have "0001" "0002" the next barcode will be "3". Should not we keep the leading zeros and generate "0003" instead? -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 30900] New: "Error searching for analytic records"
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30900 Bug ID: 30900 Summary: "Error searching for analytic records" Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Created attachment 135680 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135680&action=e… Screenshot of error message On 21.11.05 using Zebra, this message is displayed between the "New", "Edit" etc buttons, and the title of *some* records: There was an error searching for analytic records, please see the logs for details. The logs say: ==> /var/log/koha/koha/plack-error.log <== CCL parsing error (10014) Unknown qualifier ZOOM for query: Host-item=(Psychology and law =) at /usr/share/koha/lib/C4/Search.pm line 242. Warning from simple_search_compat: 'CCL parsing error (10014) Unknown qualifier ZOOM' at /usr/share/koha/lib/Koha/Biblio.pm line 540. For a while I thought the message only displayed for records with a trailing colon in 245$a, but on looking at more records that does not seem to be the case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 6419] Add customizable areas to intranet home pages
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6419 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 26910] New: When calling the effective rule (allowed reserves), the undef is now set at 0 versus undef
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26910 Bug ID: 26910 Summary: When calling the effective rule (allowed reserves), the undef is now set at 0 versus undef Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, nick(a)bywatersolutions.com When calling allowed reserves - git effective rule, if this rule is undef, the default is now set to zero. Prior to the change made in 18936, the default was set to undef. It appears this change was made "Bug 18936: Fix some more tests (19.56 KB, patch)" during this stage in the bug. In conclusion, this is very critical, as libraries will come across the inability to allow holds if they have circulation rules effective by this. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 29061] New: max_holds rule not saving a value of Unlimited
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29061 Bug ID: 29061 Summary: max_holds rule not saving a value of Unlimited Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com To recreate: - Set your Default checkout, hold and return policy value for Maximum total holds allowed (count) to 1 - find a patron, confirm you can only place 1 hold for this patron before getting a "too many holds" error - create a Checkout, hold policy by patron category for your patron's category, with a Total Holds value of Unlimited - confirm you still get a "too many holds" error, even though your circ rules say your holds should be unlimited We don't save a max_holds rule with a blank value for the patron category, so Koha ends up falling back to the more restrictive default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 15349] Problem with email pattern check on forms
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15349 --- Comment #10 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- (In reply to Katrin Fischer from comment #9) > (In reply to Tomás Cohen Arazi from comment #8) > > Bug 28870 solves the backend email validation issues, and accepts formatted > > addresses. The remaining problems are related to the jquery library we use: > > > > https://jqueryvalidation.org/email-method/ > > > > one path for solving it, could be trying to extract the regex from > > Email::Address and override the one in the jQuery library with it. Another > > option could be to add a route for email validation so an async check is > > done. > > I missed this comment, so it looks like they should not cause issues and > it's only a matter of the validation now, right? You mean validating in the form. Right? I'm that case, that's what I think -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15349] Problem with email pattern check on forms
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15349 --- Comment #9 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Tomás Cohen Arazi from comment #8) > Bug 28870 solves the backend email validation issues, and accepts formatted > addresses. The remaining problems are related to the jquery library we use: > > https://jqueryvalidation.org/email-method/ > > one path for solving it, could be trying to extract the regex from > Email::Address and override the one in the jQuery library with it. Another > option could be to add a route for email validation so an async check is > done. I missed this comment, so it looks like they should not cause issues and it's only a matter of the validation now, right? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15048] Genre/Form (655) searches fail on searches with $x 'General subdivision' subfield values
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15048 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply --- Comment #19 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Can we please have a rebase? Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 15048 - subject/genre (650/655) searches fail on searches with $x 'General subdivision' subfield values Applying: Bug 15048: Index all possible searched subfields for index-term-genre Using index info to reconstruct a base tree... M etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml M etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl Falling back to patching base and 3-way merge... Auto-merging etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl CONFLICT (content): Merge conflict in etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl Auto-merging etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml CONFLICT (content): Merge conflict in etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml error: Failed to merge in the changes. Patch failed at 0001 Bug 15048: Index all possible searched subfields for index-term-genre hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-15048-Index-all-possible-searched-subfields-fo-UEZYrg.patch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8214] Create a bound with function
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8214 --- Comment #12 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I think it would be more like EasyAnalytics (actually that could be used as a bound with). There would only be one physical thing, so only one barcode to check out.. and ideally you'd see it's gone on all the records/titles it contains. -- You are receiving this mail because: You are watching all bug changes.

1 0