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

[Bug 30365] New: editing existing records that are greater than 100 characters long brings up the textarea method of input
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30365 Bug ID: 30365 Summary: editing existing records that are greater than 100 characters long brings up the textarea method of input Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: courtenay.johnson(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Cataloging individual records using Frameworks. Using version 21.05.03 running on Ubuntu. Looking at the adddbiblio.pl code, (near line 445) I see that editing existing records that are greater than 100 characters long brings up the textarea method of input, and newlines are accepted. However if the existing shorter input, or any new input is forced to a single line text box and \n are ignored. My point is it is ridiculous that accepting of \n from the keyboard is acceptable during some conditions, but not others. As I have submitted in a bug report 30364 I also wish that the behaviour of the HTML input field should not vary if a plugin is present. I propose that a new flag in the framework should determine if a subfield will use the HTML input text or the textarea for input, and thus whether or not \n is accepted, and this should allow \n in input of any length up to the maximum length usually 9999 which currently does not seem to be used. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28329] New: The items callnumber will reappear when editing the item if originally blanked out
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28329 Bug ID: 28329 Summary: The items callnumber will reappear when editing the item if originally blanked out Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Set system preference, itemcallnumber, to 082ab or something similar to pull the call number from the bib record into the item holding. 2. Create item and remove the call number. 3. See that the callnumber has been removed in the item. 4. Edit this same item and see that the call number is back (pulled again from the marc record following the itemcallnumber sys pref). This is an issue if a library does not want a callnumber in some records but does for others. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28712] New: Printed slips for fees come up empty if no notice is defined for the user's preferred language
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28712 Bug ID: 28712 Summary: Printed slips for fees come up empty if no notice is defined for the user's preferred language Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When printing slips for account actions and using the TanslatedNotices feature, there is no fallback to "default", when there is not notice template for the user's preferred language. See bug 28487 for a similar instance of this. To test: - Create a manual fee of any kind - Pay it - Click on "print" and confirm the slip comes up with content - Turn on TranslateNotices system preference - Repeat "print" action - the slip should still print - Edit your patron and set a language other than "default" - Repeat print, the page now comes up empty I think this is quite hard to understand track down for users to figure out, so while there is a workaround (setting the notices) we should really fix it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 26300] New: Error in ISBD view in OPAC
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26300 Bug ID: 26300 Summary: Error in ISBD view in OPAC Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hblancoca(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org when I try to connect in OPAC to https://catalogo.urosario.edu.co/cgi-bin/koha/opac-ISBDdetail.pl?biblionumb… View this error Software error: The method Koha::Item->itemtype is not covered by tests! Trace begun at /usr/share/koha/lib/Koha/Object.pm line 780 Koha::Object::AUTOLOAD('Koha::Item=HASH(0x564b373f19d0)') called at /usr/share/koha/lib/Koha/Item.pm line 478 Koha::Item::__ANON__ at /usr/share/koha/lib/Koha/Item.pm line 478 Koha::Item::hidden_in_opac('Koha::Item=HASH(0x564b373f19d0)', 'HASH(0x564b3659bcf0)') called at /usr/share/koha/lib/Koha/Biblio.pm line 258 Koha::Biblio::__ANON__ at /usr/share/koha/lib/Koha/Biblio.pm line 258 Koha::Biblio::hidden_in_opac('Koha::Biblio=HASH(0x564b35160c78)', 'HASH(0x564b37636218)') called at /usr/share/koha/opac/cgi-bin/opac/opac-ISBDdetail.pl line 91 But in staff all works fine -- You are receiving this mail because: You are watching all bug changes.

1 13

[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 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 26347] New: Wrong publication pattern locale on months
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26347 Bug ID: 26347 Summary: Wrong publication pattern locale on months Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Configuring publication patterns with locale ca-ES we have discovered that months are wrong translated january = gener and now it is translating = de gener februry = febrer and now it is translating = febrer march.....etc locale should use just months not full name -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5