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

[Bug 17611] New: Searching for orders uses misleading column name " Pending order"
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '20

13 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17611 Bug ID: 17611 Summary: Searching for orders uses misleading column name "Pending order" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org Steps to reproduce: 1) Open the Acquisition module 2) At the top of the page click "Orders search" 3) Fill-in a book title that has been already received and submit the form 4) Title is found displaying (among others) these columns: - Quantity received - Pending order The Pending order is NOT pending, in fact. The header should be renamed to "Quantity ordered". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 18895] New: Lost Items Not Removed From Patron' s Account When Charge is Paid
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '20

11 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18895 Bug ID: 18895 Summary: Lost Items Not Removed From Patron's Account When Charge is Paid Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, There is a potentially severe problem when paying the replacement charge for an item if the item is still checked-out to a patron. For example, if your cronjob is set to mark an item lost and you charge patrons for lost items, using anything other than the 'pay' button will not remove the item from the patron's checkouts after the charge has been paid. 'Pay selected,' 'Pay amount,' Write off,' or 'Write off all' will take care of the charge, but the item will remain checked-out and marked as 'Long Overdue / Lost' on the patron's record. Additionally, it is difficult to identify these erroneous items if staff does not catch it them immediately, making it hard to correct lingering problems. To replicate: 1.) Set preference WhenLostChargeReplacementFee to 'Charge' 2.) Edit the record of a checked-out item to the lost status indicated by your DefaultLongOverdueChargeValue. Note: To keep the item checked-out, this must be done by opening and editing the item's record (not directly from the items tab of the bibliographic record). You can also use an item that your longoverdue cronjob marked. 3.) Confirm that the item is still checked-out to the patron and that the replacement fee was charged. 4.) Use pay selected, pay amount, write off, or write off all with the replacement charge and confirm the action as you normally would. 5.) The charge will be removed but the item will still be checked-out to the patron's record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 18790] New: Add ability to void payments
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '20

11 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18790 Bug ID: 18790 Summary: Add ability to void payments 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 18786 We've had the ability to 'reverse' a payment for a long time, but it would be much better if we had a true void payment function that replaces the paid amounts into the fee so that it appears as if the payment was never made. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18786 [Bug 18786] Add ability to create custom payment types -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 19164] New: Allow MARC modification templates to be used in staged MARC imports
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '20

10 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19164 Bug ID: 19164 Summary: Allow MARC modification templates to be used in staged MARC imports Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: J.P.Knight(a)lboro.ac.uk QA Contact: testopia(a)bugs.koha-community.org In Bug 18690 Katrin Fischer suggested that it would be useful to have MARC Modification Templates used in stage MARC imports in a similar way to that enhancement's inclusion in bulkmarcimport.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 16719] New: LDAP: Using empty strings as 'failsafe' attribute mapping defeats database constraints
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16719 Bug ID: 16719 Summary: LDAP: Using empty strings as 'failsafe' attribute mapping defeats database constraints Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: oliver.bock(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Created attachment 52316 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52316&action=ed… Patch: proper NULL mapping LDAP attributes with empty values are currently mapped as empty strings, which is described as 'failsafe'. This defeats the existing database constraints (NULL and UNIQUE) without an apparent need. If some kind of empty default is required, it should be set in the mapping config itself, not the code. Please note that this is not just a semantic issue since mapping empty LDAP values as an empty string does indeed cause a constraint violation (read: database error, hence our severity) when such an attribute bears a UNIQUE constraint. This is due to the fact that an empty string is an actual value validated by the constraint (NULL isn't). I don't know the reasoning behind the empty-string mapping but should a NULL-mapping have been the original intention then please note that this behavior is database-dependent. The correct way to map NULL in a database-agnostic way is to use "undef" (see my patch). Thanks -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 15860] New: Alias missing for /plugin on packages
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15860 Bug ID: 15860 Summary: Alias missing for /plugin on packages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Created attachment 48235 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48235&action=ed… Broken image There is an alias missing on the packages-shipped apache templates. It prevents some things to show on the UI. To test: - Enable the plugins - Install libmarc-lint-perl - Install the MARC checker plugin (https://github.com/bywatersolutions/koha-plugin-marc-checker) - Run the plugin => FAIL: There's a broken image link (see attachment) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 19489] New: Development for fines and Fees Module - Detailed Description of charges in Patron Account Tab /Fines Tab
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '20

06 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19489 Bug ID: 19489 Summary: Development for fines and Fees Module - Detailed Description of charges in Patron Account Tab/Fines Tab Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries would like to see the item barcode, due date, and return date ( if any ) for fines in the accounts tables related to fines ( pay.pl and boraccount.pl ). -- You are receiving this mail because: You are watching all bug changes.

1 77

[Bug 19676] New: Debian 9 vs. Plack vs. / tmp -- attention to PrivateTmp for apache2
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '20

05 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19676 Bug ID: 19676 Summary: Debian 9 vs. Plack vs. /tmp -- attention to PrivateTmp for apache2 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Beware: in Debian 9 apache2 comes with PrivateTmp enabled by default. As a consequence, there are issues when Plack is enabled for an instance, but in Koha there is an interaction between Plack enabled and Plack blacklisted stuff through /tmp directory. Plack-ed scripts will write temporary files in "real" /tmp directory (as pointed by Koha::UploadedFile::temporary_directory, i.e. File::Spec->tmpdir) whereas Plack blacklisted scripts will understand /tmp as private tmp of apache2, i.e. /tmp/systemd-private-?????????-apache2.service-????/tmp. This happens for instance for stage-marc-import.pl -- in step 2 the script won't find the marc file uploaded in step 1. The simplest instant solution to this would be to disable PrivateTmp for apache2 (this article gives a clue: https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html) but maybe there is a better option? (When Plack is disabled everything seems to work fine apart of the fact that the private tmp of apache2 is being used.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 16758] New: Caching issues in scripts running in daemon mode
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '20

02 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16758 Bug ID: 16758 Summary: Caching issues in scripts running in daemon mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org As L1 cache does not have expiration mechanism, scripts running in daemon mode (rebuild_zebra.pl -daemon, sip server ?, ...) would not be aware of any possible changes in the data being cached in Koha::Cache. While adding expiration functionality to Koha::Cache would be pretty simple, I guess we don't really want to expire things by default after a given amount of seconds, that would not be good for overall performance; default expiration time for L2 = memcached is infinite (intentionally). Note that it's also infinite for L2 = Cache::Memory - probably not intentional, more likely that's because this code # Default cache time for memory is _always_ short unless it's specially # defined, to allow it to work reliably in a persistent environment. my $cache = Cache::Memory->new( 'namespace' => $self->{'namespace'}, 'default_expires' => "$self->{'timeout'} sec" || "10 sec", ); doesn't work as advertised. That might be a problem for plack + Cache::Memory setups - hopefully nobody uses such weird combos. Anyway, that belongs to the separate bug report. I wonder what would be a best approach for solving this issue for perpetually running scripts? Maybe just adding a function to Koha::Cache which flushes L1 cache (but not more often then each 10 | 20 | 30 seconds), and call it in rebuild_zebra.pl etc. daemon loop - ? -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 18379] New: ejournal add
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '20

26 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18379 Bug ID: 18379 Summary: ejournal add 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: sunitabarve(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com For renewing ejournals there is only a need of subscription period and no need to add issues. But this feature is not there for renewing ejournals through serials. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3