May 2015 - Koha-bugs - lists.koha-community.org

[Bug 12025] New: Inventory tool fails with "Could not reads headers", or sometimes a timeout
by bugzilla-daemon＠bugs.koha-community.org 04 May '15

04 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12025 Bug ID: 12025 Summary: Inventory tool fails with "Could not reads headers", or sometimes a timeout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: jason(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 26759 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26759&action=edit sample file This happens with small test files of one or two barcodes. jason-temp@lumen:~$ od BARCODES.TXT 0000000 030063 033065 030463 030060 030060 030060 033062 031412 0000020 032460 031466 030061 030060 030060 031460 000064 0000035 jason-temp@lumen:~$ cat BARCODES.TXT 30563100000026 30563100000034jason-temp@lumen:~$ On the server side, it looks inventory.pl spins out of control, and is looping on commands like this: write(5, "s\0\0\0\3select authorised_value fro"..., 119) = 119 read(5, "\1\0\0\1\1h\0\0\2\3def\4salt\27marc_subfield"..., 16384) = 144 poll([{fd=5, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) write(5, "Y\0\0\0\3select authorised_value, li"..., 93) = 93 read(5, "\1\0\0\1\3\\\0\0\2\3def\4salt\21authorised_va"..., 16384) = 337 poll([{fd=5, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) write(5, "\1\0\0\0\16", 5) = 5 read(5, "\7\0\0\1\0\0\0\2\0\0\0", 16384) = 11 poll([{fd=5, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) write(5, "\1\0\0\0\16", 5) = 5 read(5, "\7\0\0\1\0\0\0\2\0\0\0", 16384) = 11 poll([{fd=5, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) This is with Koha 3.14.03.000, but Chris Cormack confirmed that it happens with master, 3.14.1, and 3.14.5, but that it works fine on 3.12.12. He tracked it down to this commit for this bug: 0313856d9a1a9c0c002da0aead8c8516b51e1c11 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7684 There is an email thread discussing this on the Koha list: http://lists.katipo.co.nz/public/koha/2014-March/039092.html http://lists.katipo.co.nz/public/koha/2014-April/thread.html#39127 With the Chrome development tools, I also see the following errors when I first load the interface: Uncaught SyntaxError: Unexpected token ILLEGAL inventory.pl:62 event.returnValue is deprecated. Please use the standard event.preventDefault() instead. jquery.js:3 Let me know if there's anything else I can do to help. Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 14011] New: Triggering slip print with enter key collides with 'barcode submitted' message
by bugzilla-daemon＠bugs.koha-community.org 04 May '15

04 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14011 Bug ID: 14011 Summary: Triggering slip print with enter key collides with 'barcode submitted' message 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, kyle(a)bywatersolutions.com To test: - submit empty checkout for triggering a slip print - print the slip or cancel - notice you can't read a new barcode into the field now, instead, the 'barcode submitted' message will be triggered each time you try -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 14140] New: Reversed payments don't generate entry in statistics
by bugzilla-daemon＠bugs.koha-community.org 04 May '15

04 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14140 Bug ID: 14140 Summary: Reversed payments don't generate entry in statistics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We are tracking payments in the statistics table, but when a payment gets reversed, the data you can get from there is not correct. We should also be tracking reversed payments so it's possible to calculate the correct amounts from the statistics table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 12036] New: Neworderempty.pl fails to add items when itemrecorddisplay is too long (acqCreateItem=ordering)
by bugzilla-daemon＠bugs.koha-community.org 04 May '15

04 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12036 Bug ID: 12036 Summary: Neworderempty.pl fails to add items when itemrecorddisplay is too long (acqCreateItem=ordering) Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org In 3.14.4 I encounter this problem in Acquisition, neworderempty.pl: The output of PrepareItemrecordDisplay (called by itemrecorddisplay.pl in additem.js [cloneItemBlock]) seems to be too long. The line $(clone).append(data) in the ajax success function in cloneItemBlock fails silently. This makes it impossible to add items to a new empty order when AcqCreateItem=ordering. Did anyone else see that already or solved it? (I created the ACQ framework by just copying from Default.) On a clean master I could not reproduce this problem, but it seemed that the output of PrepareItemrecordDisplay was around 23000 there instead of 27000 chars. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 12348] New: unique barcodes should be mandatory
by bugzilla-daemon＠bugs.koha-community.org 04 May '15

04 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12348 Bug ID: 12348 Summary: unique barcodes should be mandatory Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Partner has an item that shows 'check-in failed' in the 'Check-in' column in circulation.pl. When the item is brought up in holdings, there is no link to click on to allow editing. All library interaction with items (check-in, check-out, item edit) require bar codes, but there are no integrity checks in Koha (in the database or perl code) to ensure that all items must have barcodes. This leads to support issues when partners create items that do not have barcodes, then cannot do anything with them. Ideally, I would think that items.barcode should be defined as `barcode` varchar(20) NOT NULL If this isn't possible for historical reasons, then an effort should be made to deprecate the practice of allowing NULL barcodes by emitting obnoxious warning messages stating that NULL bar codes will not be allowed in future versions of Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 4856] New: problem with NSB/NSE chars
by bugzilla-daemon＠bugs.koha-community.org 03 May '15

03 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4856 Summary: problem with NSB/NSE chars Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Zebra doesn't like NSB/NSE chars, they should be deleted before indexing, only in UNIMARC because it's a french problem. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 9

[Bug 4857] New: aqplan.pl: consideration of Planning categories with authorised values
by bugzilla-daemon＠bugs.koha-community.org 03 May '15

03 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4857 Summary: aqplan.pl: consideration of Planning categories with authorised values Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: alex.arnaud(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 18

[Bug 4864] New: modules required by SIP not in module list
by bugzilla-daemon＠bugs.koha-community.org 03 May '15

03 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4864 Summary: modules required by SIP not in module list Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Installation and upgrade (command-line installer) AssignedTo: gmcharlt(a)gmail.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 SIPServer.pm requires Net::Server and UNIVERSAL::require which are not in the dependencies listing -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 7

[Bug 5294] New: Vendor name shows with '%20'
by bugzilla-daemon＠bugs.koha-community.org 03 May '15

03 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5294 Summary: Vendor name shows with '%20' Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 To reproduce: 1) create a new subscription 2) search for a vendor who has spaces in their name 3) choose it, and note that when its name is put into the field, it has %20 where spaces should be. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 17

[Bug 8464] New: Age limitations not handled during patron creation
by bugzilla-daemon＠bugs.koha-community.org 03 May '15

03 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8464 Priority: P5 - low Change sponsored?: --- Bug ID: 8464 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: adrien.saurat(a)biblibre.com Summary: Age limitations not handled during patron creation Severity: normal Classification: Unclassified OS: All Reporter: adrien.saurat(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Patrons Product: Koha TEST PLAN 1) Create a patron category allowing users from 10 to 20 years old. 2) Set the BorrowerMandatoryField system preference to ask for the date of birth when creating a patron. Just add "|dateofbirth" at the end of the string if the date is not there yet. 3) Create a patron with a birth date in 2012. No error message will be displayed and the patron is created even though it should have been forbidden. -- You are receiving this mail because: You are watching all bug changes.

1 13