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

[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 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

[Bug 28987] New: Record search by date broken in label management
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28987 Bug ID: 28987 Summary: Record search by date broken in label management Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 24735 If you go to Tools -> Label creator -> New batch -> Add items you'll trigger a popup window with a search form. Searching by date returns no results. I think Bug 24735, "Remove QueryParser-related code" is to blame. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24735 [Bug 24735] Remove QueryParser-related code -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 28651] New: Automatic renewal don't send out notice if status "On hold"
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28651 Bug ID: 28651 Summary: Automatic renewal don't send out notice if status "On hold" Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: somesecretemail(a)mailinator.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It seems like the cron job automatic_renewals does't create notices if the biblio is on hold by another patron. These are the steps to reproduce the bug: 1. Set date_due to current date on an issue 2. Place a hold on the biblio related to the issue 3. Run cron job automatic_renewals.pl --send-notices -c -v 4. Note feedback in terminal "Issue id: xx for borrower: xx and item: xx will not be renewed. (on_reserve)" 5. Click "Notices" on the patron which is related to the issue. Result: List lacks notice informing patron about the issue not been renewed. Expected result: Notices list containing a notice about the issue not been renewed. I tried removing the hold och rerunning the auto renew cron job. Then the issue is renewed and the notice is created correctly, so it's not a general bug in the automatic renewals functionality. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 23832] New: 001 control number auto complet or copy from 999c
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '22

16 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23832 Bug ID: 23832 Summary: 001 control number auto complet or copy from 999c Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com controlnumber 001 is an important field, I like it is empty by default at koha, but for example analytics could need to be filled... It should be great be able to choose 1. Autonumber plugin for 001 2. Autofill via daily cronjob for filling 001 copying 999c if 001 empty -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6