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

[Bug 23145] New: Confirming transfer during checkin clears the table of previously checked-in items
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '20

11 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23145 Bug ID: 23145 Summary: Confirming transfer during checkin clears the table of previously checked-in items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: cbrannon(a)cdalibrary.org, gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 21346 Target Milestone: --- Following the changes made by Bug 21346, transfers triggered during checkin result in a modal dialog asking for confirmation. When this confirmation is clicked the page reloads and the table of previously checked-in items disappears. The information in that table can be very important to librarians keeping track of what they've checked in or as a way to navigate directly to an item or patron. The modal should be dismissed without reloading the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21346 [Bug 21346] Clean up dialogs in returns.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[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 22860] New: Selenium tests authentication.t does not remove all data it created
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22860 Bug ID: 22860 Summary: Selenium tests authentication.t does not remove all data it created Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 19181 Target Milestone: --- 1 patron will remain in the DB after the tests ran. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19181 [Bug 19181] Intranet and OPAC authentication selenium test -- You are receiving this mail because: You are watching all bug changes.

1 15

[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 20708] New: Withdrawn status should show when placing a request in staff client
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20708 Bug ID: 20708 Summary: Withdrawn status should show when placing a request in staff client 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1 - Backup your db (or not, I am not your parent) 2 - Set some items as withdrawn (UPDATE items SET withdrawn = 1) 3 - Try to place some holds 4 - The screen says no items are available, but it is hard to see why 5 - Restore your database, or just live your life :-) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[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 21970] New: Scan and Go functionality
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '20

05 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21970 Bug ID: 21970 Summary: Scan and Go functionality Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A library has asked about using Scan and Go technology within Koha, much like you are seeing in commercial settings. The idea is to allow patrons to check out books using their phones, such as described in this article: https://digiday.com/marketing/7-eleven-testing-new-scan-go-technology-let-c… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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