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

[Bug 22702] New: circulation note on patron page should allow for HTML tags
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '21

15 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22702 Bug ID: 22702 Summary: circulation note on patron page should allow for HTML tags Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Some libraries like to include links and other HTML in the circulation note. This currently uses the html filter and should be switched to $raw. This should not be problematic since only staff can do this. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 27071] New: Hold pickup library match not enforced correctly on intranet when using hold groups
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27071 Bug ID: 27071 Summary: Hold pickup library match not enforced correctly on intranet when using hold groups Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests 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 Depends on: 22284 To recreate: - Create two local hold groups containing distinct lists of libraries. - In default rules for all libraries, set Hold Policy = "From local hold group" and Hold pickup library match to "Patron's hold group" - Make sure AllowHoldPolicyOverride is set to Don't Allow - Make sure you're logged in at a library in Group 1 - Find a bib with only 1 item from Group 1. Confirm you can place a hold on this title for a patron in Group 1 (correct), but not for a patron in Group 2 (correct). - Find a bib with only 1 item from Group 2. Confirm you cannot place a hold for a patron from Group 1 (correct), BUT you also cannot place a hold for a patron from Group 2 (incorrect) -- Koha gives the erroneous message "pickupNotInHoldGroup" - Change your library to a something in Group 2 - Find a bib with only 1 item from Group 1. Confirm you cannot place a hold on this title for a patron in Group 1 (incorrect), and not for a patron in Group 2 (correct). - Find a bib with only 1 item from Group 2. Confirm you cannot place a hold for a patron from Group 1 (correct), but you can place a hold for a patron from Group 2 (correct) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22284 [Bug 22284] Add ability to define groups of locations for hold pickup -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 26787] New: getletter does not fallback to default language - transaction receipts can be blank
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26787 Bug ID: 26787 Summary: getletter does not fallback to default language - transaction receipts can be blank Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org getletter does not fallback to default language, it searches for a language if passed then gives up To recreate 1 - Enable 'TranslateNotices' syspref 2 - Define ACCOUNT_CREDIT notice for print transport in default language 3 - Make sure 'English (en)' notice is not defined 4 - Make a payment on a patrons account 5 - Go to the patrons transactions and click 'Print' on the payment 6 - Is blank? 7 - Copy notice from default to english 8 - Try again, it works -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 27169] New: sip2 not enable
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '21

09 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27169 Bug ID: 27169 Summary: sip2 not enable Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: ujjwalguptax202(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com sip2 not working after use of koha-sip --enable library and koha-sip --start library when check the status it shows sip2 running but but but its not connecting when i use ip and port to connect sip2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 16181] New: Limit number of tags loaded initially for tag cloud
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '21

09 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16181 Bug ID: 16181 Summary: Limit number of tags loaded initially for tag cloud Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a patron has an large number of tags (say 3,421) the tag cloud takes an inordinately long time to load. Maybe we could enforce a limit on initial load and then allow user to load more or paginate through all? -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 22956] New: Omnibus: Remove type attribute from script tags
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '21

08 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22956 Bug ID: 22956 Summary: Omnibus: Remove type attribute from script tags Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW 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 Target Milestone: --- Bug 20053 removed all "type" attributes from <script> tags in OPAC templates.* We should do the same for the staff client templates. * A couple of regressions have made it in which need to be fixed. This bug will act as an omnibus bug for collecting bugs of smaller scope. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 16785] New: Autocomplete broken on overdues report
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '21

08 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16785 Bug ID: 16785 Summary: Autocomplete broken on overdues report Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/circ/overdue.pl OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, koha-bugs(a)lists.koha-community.org, kyle.m.hall(a)gmail.com If you have a patron attribute defined which is searchable and linked to an authorized value, that attribute will show up in the overdue report filter form as an autocomplete field. The autocomplete is broken for cases where more than one result is returned by the search. -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.

1 20

[Bug 24683] New: Holds on biblios with different item types: rules for holds allowed are not applied correctly if any item type is available
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '21

08 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24683 Bug ID: 24683 Summary: Holds on biblios with different item types: rules for holds allowed are not applied correctly if any item type is available Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hans.palsson(a)hkr.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 99257 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=99257&action=ed… An example of a biblio with mixed itemtype items. When having different rules for placing holds for each item type, having both item types on one biblio "breaks" these rules. As shown in the attachment: Smart rules for item type "Course literature" allows patrons to place holds on items. The smart rules for the item type "Dayloan" does not allow patrons to place holds on the items. When having both item types on one biblio, it should in theory be possible to place a hold on biblio level even if the dayloan item type is available. Setting the option "AllowHoldItemTypeSelection" to allow does not solve the problem. Various other options have been tried, but as long as there is an available item that is not "not for loan", then placing holds is not possible. This is troublesome for us, since holds must be placed manually by staff. The Dayloan item type is for having a copy available for many students and should not be placed on hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 64

[Bug 24855] New: Lost items not marked returned when floating-point math causes amountoutstanding to be not-quite-zero
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24855 Bug ID: 24855 Summary: Lost items not marked returned when floating-point math causes amountoutstanding to be not-quite-zero Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Floating point math and a strict "if amountoutstand=0" result in things not getting marked as returned when they should. I've had a hard time figuring out exactly when this will go wrong, so I've got some very specific steps to recreate. To test: - set MarkLostItemsAsReturned to never mark items returned - turn on Fines log - find/create a patron with no outstanding fees or fines - manually apply 8 overdue charges of $4.10 - create an item with a replacement cost of 6.99 - check item out to patron - mark item lost, generating 6.99 lost fee for patron - pay off entire balance using the Pay Amount button - confirm patron no longer owes any fees, but item has not been marked as returned when fee was paid off - check fines log, see that the accountline for this lost fee recorded a payment of "6.98999999999999" and a new amountoutstanding of "7.105427357601e-15" While we round these values to 4 decimal places in accountlines, that rounding happens *after* Koha checks if amountoutstanding=0 when deciding whether or not to mark the lost item returned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 27660] New: Should getletter not use the fallback to default ?
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27660 Bug ID: 27660 Summary: Should getletter not use the fallback to default ? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Looking at the code: sub getletter { my ( $module, $code, $branchcode, $message_transport_type, $lang) = @_; .. $lang = 'default' unless( $lang && C4::Context->preference('TranslateNotices') ); .. my $sth = $dbh->prepare(q{ SELECT * FROM letter WHERE module=? AND code=? AND (branchcode = ? OR branchcode = '') AND message_transport_type LIKE ? AND lang =? ORDER BY branchcode DESC LIMIT 1 }); $sth->execute( $module, $code, $branchcode, $message_transport_type, $lang ); my $line = $sth->fetchrow_hashref or return; .. I am just wondering if I miss something. If the language is passed (which is often just a $patron->lang or so), then we are fetching with that language! If that notice has not been translated yet, we will not fallback to en ?! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15