December 2018 - Koha-bugs - lists.koha-community.org

[Bug 14591] book drop / drop box mode incorrectly decrements accrued overdue fines
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14591 --- Comment #4 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- (In reply to Kyle M Hall from comment #3) > I think the solution is to remove all the dropbox code, and make dropbox > mode just be a backdated return which backdates to the last day the library > was previously open. I think we now have the account offsets, and can rewrite _FixOverduesOnReturn as I did with _FixAccountForLostAndReturned, to take them into account. We need to: - Make sure each 'increment' actually creates an offset (this of course should be possible with $line->adjust from bug 21727) - Replace the current code so it doesn't touch 'amount'. It should calculate the amount to substract, and create a special type of credit. If there was a writeoff, skip that writeoff amount, if there was a (maybe partial) payment, refund it with a CR account line. So: my $amount = calaculate_amount_to_backtrack_skipping_writeoffs({ $fine_line }); $account->add_credit({ amount => $amount, type => 'credit_return' })->apply({ debit => $fine_line }); -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3849] Descriptions of acquisition permissions are unclear
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3849 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |21966 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21966 [Bug 21966] Fix descriptions of acquisition permissions to be more clear (again) -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 12144] Book drop mode mode erasing fine when CalculateFinesOnReturn is enabled
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12144 --- Comment #3 from Kyle M Hall <kyle(a)bywatersolutions.com> --- I think the solution is to remove all the dropbox code, and make dropbox mode just be a backdated return which backdates to the last day the library was previously open. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14591] book drop / drop box mode incorrectly decrements accrued overdue fines
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14591 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle(a)bywatersolutions.com --- Comment #3 from Kyle M Hall <kyle(a)bywatersolutions.com> --- I think the solution is to remove all the dropbox code, and make dropbox mode just be a backdated return which backdates to the last day the library was previously open. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14591] book drop / drop box mode incorrectly decrements accrued overdue fines
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14591 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs(a)lists.koha-commun |tomascohen(a)gmail.com |ity.org | CC| |tomascohen(a)gmail.com --- Comment #2 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- This is still valid. 'lastincrement' is not enough to determine how much to roll back. This also has the side effect of making debits (the accruing fine) be converted into a credit if it was partially payed or there was a writeoff (this could be the case for a patron having outstanding credit and it being applied automatically as proposed in bug 21915). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 20261] New: No result in some page in authority search opac and pro (ES)
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20261 Bug ID: 20261 Summary: No result in some page in authority search opac and pro (ES) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire.hernandez(a)biblibre.com How I reproduce this issue: * apply bug 17373 (auth unimarc mapping) * mappings.pl?op=reset&i_know_what_i_am_doing=1 * reindex autorities - ex: rebuild -a -v -d * authority search in opac or pro, looking for a term used * page 1 => OK, I see results * clic on page 2 => OK, I see results * clic on page 3 => KO, no result * clic on the lasty page displayed => KO (another), with an error ==> error.log <== [Wed Feb 21 10:30:11 2018] authorities-home.pl: [Request] ** [http://elastic:80]-[500] {"error":{"root_cause":[{"type":"query_phase_execution_exception","reason":"Result window is too large, from + size must be less than or equal to: [10000] but was [10020]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"koha_maedi_authorities","node":"hhR2RjsnSye_jPUnySnMkQ","reason":{"type":"query_phase_execution_exception","reason":"Result window is too large, from + size must be less than or equal to: [10000] but was [10020]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."}}]},"status":500}, called from sub Search::Elasticsearch::Role::Client::Direct::__ANON__ at /usr/share/perl5/Catmandu/Store/ElasticSearch/Bag.pm line 167. With vars: {'status_code' => 500,'request' => {'method' => 'GET','path' => '/koha_maedi_authorities/data/_search','serialize' => 'std','body' => {'size' => 20,'from' => 10000,'sort' => [{'Heading__sort.phrase' => 'asc'}],'query' => {'bool' => {'should' => [{'match' => {'Heading-Main' => 'de'}}]}}},'qs' => {},'mime_type' => 'application/json','ignore' => []}} [Wed Feb 21 10:30:11 2018] authorities-home.pl: Unable to perform your search. Please try again. I don't know if it is a mapping problem or a page management issue in authority search. To be investigated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 14391] Granular permissions for the administration module
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14391 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |21961 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21961 [Bug 21961] Typo in permission keeps Did you mean? config from showing up -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21960] New: Add description to manage_didyoumean permission
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21960 Bug ID: 21960 Summary: Add description to manage_didyoumean permission 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The manage_didyoumean patron permission has no description. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 18900] New: Receiving order with unitprice multiples by 1000
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18900 Bug ID: 18900 Summary: Receiving order with unitprice multiples by 1000 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 18471 added number formating in order receive. I found a bug generated by this. Koha::Number::Price defines methods to (un)format price depending on CurrencyFormat syspref. The bug is that for CurrencyFormat US, some params are not defined in this module so there are retrieved from system locale. If system locale is not en_US, the params will be wrong. For example fr_FR will define , as decimal and so multiple price value by 1000. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 18471] New: Receiving order with unitprice greater than 1000 processing incorrectly
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '18

06 Dec '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18471 Bug ID: 18471 Summary: Receiving order with unitprice greater than 1000 processing incorrectly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Two problems here really: Receiving orders process the comma as a decimal point Invoices are displaying incorrectly when formatting total To recreate: 1 - Open a basket 2 - Place an order for an item with price > 1000, $4367.00 for example 3 - Close basket 4 - Receive order 5 - Note on orderreceive.pl the price is populate as "4,367.00" 6 - Receive/Save 7 - Note the 'Actual Cost' is now $4.00, verify db contains 4 as well 8 - Cancel receipt 9 - Receive again, this time enter price as "4367" 10 - Receive/save 11 - Note actual cost is correct 12 - Finish receiving 13 - Note invoice reads total as $4.00 14 - Check db - price in aqorders is correct but displaying incorrectly -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29