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

[Bug 26533] New: Searching authorities using 'is exactly' doesn't work as expected
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '22

18 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26533 Bug ID: 26533 Summary: Searching authorities using 'is exactly' doesn't work as expected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When searching authorities using the 'is exactly' limiter, it's expected that the search term needs to match the authority heading EXACTLY. However, it appears to match on any word in the authority heading. For example, I have an authority called 'Atlantic salmon fishing Ireland'. I am able to get search results for this authority when searching 'is exactly' 'atlantic'. But obviously, the heading is not exactly atlantic. So I shouldn't get results from this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 28746] New: Add OPAC equivalent for RestrictionBlockRenewing system preference
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '22

18 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28746 Bug ID: 28746 Summary: Add OPAC equivalent for RestrictionBlockRenewing system preference 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref RestrictionBlockRenewing determines whether or not a restriction prevents renewal of an item via the intranet. There is not currently a way to allow patrons to renew their own items via the OPAC when restricted. For libraries applying restrictions automatically via the overdues process, this can be overly restrictive. Some libraries would prefer to give patrons the option of renewing on the OPAC, thereby clearing their own restriction. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28069] New: Can't sort lists on 'Contents'
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '22

17 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28069 Bug ID: 28069 Summary: Can't sort lists on 'Contents' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On staff client, it's not possible to sort lists by 'Contents'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

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