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

[Bug 12620] Proxy Add-on for Koha z39.50/SRU servers
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '21

07 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12620 --- Comment #10 from David Cook <dcook(a)prosentient.com.au> --- I've heard back from Adam Dickmeiss at Indexdata, and he said "you should be able to use [the connect syntax] for most client software of YAZ". So that's interesting! I'm tempted to do some testing, and build this functionality into Koha. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 13307] Create a link to the last advanced search in search result page (OPAC)
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '21

05 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13307 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |28518 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28518 [Bug 28518] "Return to the last advanced search" exclude keywords if more than 3 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28517] New: Bad encoding in logged-in-branch-name
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28517 Bug ID: 28517 Summary: Bad encoding in logged-in-branch-name Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: resetka.bedi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 121632 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121632&action=e… Staff page with Set library. The problem is in upper right. There was no problem in previous versions. Now, after installing version 21.05, the library name is displayed incorrectly in the upper right (HTML class logged-in-branch-name). It should be correct as it is in the Set library: Bédiho knihovna. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[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 15449] Move stuff to the Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15449 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |28514 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28514 [Bug 28514] C4::Letters::getletter must be rewritten -- You are receiving this mail because: You are watching all bug changes.

1 0

[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

[Bug 14261] Switch 'ask for a discharge' to 'download discharge confirmation' when patron was discharge in OPAC user account
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14261 --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Katrin Fischer from comment #6) > Would still love some help with fixing my patch! Still looking for someone to help me out here :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11158] Authorities 'starts with' search returns the same as 'contains' when using ICU
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11158 --- Comment #12 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- The test plan works ok on current master for me, but I assume this is because the kohadevbox is using ICU by default. I am not sure how to activate ICU there. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27781] New: Editing Codes
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27781 Bug ID: 27781 Summary: Editing Codes Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I understand the need to not allow code editing once a code has been created for tables. However, I am wondering if we could consider another approach. It is risky, but might provide more flexibility with editing. This would be particularly helpful to those of us that mistype a code, or create a code, only to realize that sorting in dropdowns is based on order of the code, not the description. What if we added an option to change the code, and the process would A) check related tables to make sure the suggested change doesn't already exist, and B) change all instances of that code in related tables. If there are flaws with this process, or it is too risky, I understand. I am just one of those people that hates it when you make a mistake and then it lives in your database for eternity. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 27866] New: cannot create new printer profiles
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27866 Bug ID: 27866 Summary: cannot create new printer profiles Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org to recerate: -go to Home › Tools › Label creator › Profiles › New printer profile (/cgi-bin/koha/labels/label-edit-profile.pl?op=new) -attempt to save a new printer profile -get an error C4::Creators::Profile::save(): DBI Exception: DBD::mysql::st execute failed: Incorrect integer value: '' for column 'template_id' at row 1 [for Statement "INSERT INTO printers_profile (printer_name, offset_vert, creep_vert, paper_bin, template_id, creep_horz, units, creator, offset_horz) VALUES (?,?,?,?,?,?,?,?,?);" with ParamValues: 0="e", 1=0, 2=0, 3="e", 4='', 5=0, 6="MM", 7='Labels', 8=0] at /kohadevbox/koha/C4/Labels/Profile.pm line 23 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1