October 2014 - Koha-bugs - lists.koha-community.org

[Bug 12647] New: QueryParser fails tests
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12647 Bug ID: 12647 Summary: QueryParser fails tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org QueryParser.t will usually fail using a more current perl. Here are two runs of QueryParser.t using perl 5.18.1 ~/kohaclone$ prove t/QueryParser.t t/QueryParser.t .. 1/? # Failed test 'super simple keyword query' # at t/QueryParser.t line 22. # got: '@attr 1=1003 @attr 4=6 "smith"' # expected: '@or @or @attr 1=1016 @attr 4=6 "smith" @attr 9=20 @attr 2=102 @attr 4=6 "smith" @attr 9=34 @attr 2=102 @attr 4=6 "smith"' # Failed test 'keyword search sorted by acqdate descending' # at t/QueryParser.t line 33. # got: '@or @attr 7=1 @attr 1=32 0 @attr 1=1003 @attr 4=6 "smith"' # expected: '@or @attr 1=32 @attr 7=1 0 @attr 1=1003 @attr 4=6 "smith"' # Looks like you failed 2 tests of 28. t/QueryParser.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/28 subtests Test Summary Report ------------------- t/QueryParser.t (Wstat: 512 Tests: 28 Failed: 2) Failed tests: 6, 17 Non-zero exit status: 2 Files=1, Tests=28, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.17 cusr 0.01 csys = 0.21 CPU) Result: FAIL ~/kohaclone$ prove t/QueryParser.t t/QueryParser.t .. 1/? # Failed test 'super simple keyword query' # at t/QueryParser.t line 22. # got: '@attr 1=4 @attr 4=6 "smith"' # expected: '@or @or @attr 1=1016 @attr 4=6 "smith" @attr 9=20 @attr 2=102 @attr 4=6 "smith" @attr 9=34 @attr 2=102 @attr 4=6 "smith"' # Failed test 'relevance-bumped query' # at t/QueryParser.t line 26. # got: '@attr 1=4 @attr 2=102 @attr 9=20 @attr 4=6 "smith"' # expected: '@attr 1=4 @attr 9=20 @attr 2=102 @attr 4=6 "smith"' # Failed test 'keyword search sorted by acqdate descending' # at t/QueryParser.t line 33. # got: '@or @attr 7=1 @attr 1=32 0 @attr 1=1003 @attr 4=6 "smith"' # expected: '@or @attr 1=32 @attr 7=1 0 @attr 1=1003 @attr 4=6 "smith"' # Looks like you failed 3 tests of 28. t/QueryParser.t .. Dubious, test returned 3 (wstat 768, 0x300) Failed 3/28 subtests Test Summary Report ------------------- t/QueryParser.t (Wstat: 768 Tests: 28 Failed: 3) Failed tests: 6, 10, 17 Non-zero exit status: 3 Files=1, Tests=28, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.18 cusr 0.01 csys = 0.23 CPU) Result: FAIL The nature of the fails suggests that the parser is assuming that elements in a hash are ordered and generating the query from that. While that has never been the case current versions of perl ensure that hash elements are not returned in the same sequence as a predictable one was a security weakness. So if running with a later perl the dequence of elements in the generated query is random -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 10172] New: The MARC Preview link could be hidden when printing a record
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10172 Bug ID: 10172 Summary: The MARC Preview link could be hidden when printing a record Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: mathieu.saby(a)univ-rennes2.fr When you print a record, you can see the new "MARC Preview" link under the record. It is useless, as you can click on your sheet of paper ;-) M. Saby -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 12906] New: Show shipment date in invoices result list
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '15

24 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12906 Bug ID: 12906 Summary: Show shipment date in invoices result list 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It would be nice if the shipment date was included in the result list when searching invoices. This is the date most libraries enter, while the other dates (billing date and closing date) are not always used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 10819] New: Allow for auto filling of holds when items are checked in via SCO
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '15

24 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10819 Bug ID: 10819 Summary: Allow for auto filling of holds when items are checked in via SCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cnighswonger(a)foundations.edu QA Contact: testopia(a)bugs.koha-community.org When an item with a hold on it is checked in via the SCO module (web), no further processing is done which results in the hold being overlooked unless the circulation desk workflow includes a regular run of the hold reports. The least fix for this would be to add a system pref allowing for the option of auto-filling the highest priority hold on an item checked in via the SCO module. Perhaps other options allowing for various alternate workflows might be added here as well. I'm listing this as an enhancement because depending on one's workflow, this may not be a bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8950] New: Patron Card Creator_Background Image and barcode
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '15

23 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8950 Priority: P5 - low Change sponsored?: --- Bug ID: 8950 Assignee: gmcharlt(a)gmail.com Summary: Patron Card Creator_Background Image and barcode Severity: enhancement Classification: Unclassified OS: All Reporter: sophina0516(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Tools Product: Koha Our patron card design has a background image, which is the same size as the plastic card, (2" height * 3.25" width).If we prefer to locate the barcode at the front of the card, the barcode will be covered by the background image. Just wondering that ----Is there a way that we can bring the barcode to front of the background image? http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=patroncards/creat… -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 12144] New: Book drop mode mode erasing fine when CalculateFinesOnReturn is enabled
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12144 Bug ID: 12144 Summary: Book drop mode mode erasing fine when CalculateFinesOnReturn is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical 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 When returning items with Book drop mode mode enabled and CalculateFinesOnReturn set to "calculate", the amountoutstanding for a fine, no matter how large, is reduced to 0.00 To reproduce: 1) Fine a patron with and overdue item that has fines 2) Ensure CalculateFinesOnReturn is enabled 3) Browse to the returns screen, check the "Book drop mode" but *not* the "Forgive overdue charges" box 4) Return the item 5) Check the fine for that item, it should now be reduced to 0.00 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 13044] New: Deprecate old dropbox mode
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13044 Bug ID: 13044 Summary: Deprecate old dropbox mode 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We now have two ways to backdate returns, the older "Book drop" mode, and the newer arbitrary backdating of returns feature. We should deprecate the older mode by having the "Book drop" checkbox insert the date the library was last open into the date field. We would also need to remove the system preference to have the returns backdating feature always on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 11512] New: Forced holds that violate issuing rules will never be filled
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11512 Bug ID: 11512 Summary: Forced holds that violate issuing rules will never be filled 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently in Koha, if you choose to force a hold from the staff side that would contravened the current issuing rules, that hold will never be filled, as it is always skipped over by CheckReserves. I think the only way to resolve this is to add a flag to the reserves table to alert the system that despite the fact that this hold should usually be skipped over, in this case, it should not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 12160] New: Rename intranetuserjs to IntranetUserJS
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12160 Bug ID: 12160 Summary: Rename intranetuserjs to IntranetUserJS Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ... to match IntranetUserCSS The same should be done with opacuserjs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 8190] New: Koha does not have a logging module
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '15

21 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190 Priority: P5 - low Change sponsored?: --- Bug ID: 8190 Assignee: gmcharlt(a)gmail.com Summary: Koha does not have a logging module Severity: enhancement Classification: Unclassified OS: All Reporter: jonathan.druart(a)biblibre.com Hardware: All Status: NEW Version: unspecified Component: Architecture, internals, and plumbing Product: Koha I would be great to specify a log level (to differentiate production and development environment for example). -- You are receiving this mail because: You are watching all bug changes.

1 144