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

[Bug 4925] New: Remove Smithsonian as a delivered z39.50 target
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4925 Summary: Remove Smithsonian as a delivered z39.50 target Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 I propose to remove Smithsonian Institution as a delivered sample z39.50 target for several reasons. Its collection would seem to be of limited utility for most libraries. Also, and more important, I spent a long time working with them on search problems a while back. Something has changed on their server which seems to require particular search attributes to be sent as part of the search. As it stands now in Koha, only a raw (keyword) search and an author search will produce any results. A title search fails unless it's the full, exact title -- no partial entries. ISBN/ISSN, subject headings, LC call number, and other searches all fail even if a known entry is sent. Koha is using title attr 1=4 for all z39.50 title search, as near as I can tell, and Smithsonian says they're set to use 44. Similar for subject -- Koha is set to 21 and Smithsonian is using 121. A manual yaz z39.50 search specifying the right attributes does work on Smithsonian, but changing them would screw up other z39.50 searches that are now working properly. Any objections to just removing Smithsonian from the list? -- 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 19

[Bug 14185] New: Noisy warns in opac-readingrecord.pl
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14185 Bug ID: 14185 Summary: Noisy warns in opac-readingrecord.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org If $limit is left undefined it causes a warn in error log -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 14186] New: Noisy warns in opac-reserve.pl
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14186 Bug ID: 14186 Summary: Noisy warns in opac-reserve.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org If $reservedfor is undefined, a warn comes up in error log -- You are receiving this mail because: You are watching all bug changes.

1 19

[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 14206] New: notice using only the 'print' template can't be deleted
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14206 Bug ID: 14206 Summary: notice using only the 'print' template can't be deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: P3 Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: indradg(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Use-case: Wanted a 'letter' that will only be printed and NOT emailed. What I found: 1/ can define and save such a letter with only the print template filled 2/ letter shows up in the list or letters with 'edit' and 'delete' links next to it 3/ edit works fine, but delete doesn't work. In fact, with delete, the <td> values of library, module, code and name are not displayed. 4/ delete does not work for a letter using print only template To delete: Edit the letter and add a 'print' template (additionally). Now the letter can be deleted. Question: is this the correct / expected behaviour? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 14025] New: Implement OPACURLOpenInNewWindow for NORMARC
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14025 Bug ID: 14025 Summary: Implement OPACURLOpenInNewWindow for NORMARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: magnus(a)enger.priv.no Reporter: magnus(a)enger.priv.no QA Contact: testopia(a)bugs.koha-community.org NORMARC XSLT does not support OPACURLOpenInNewWindow. It should. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 14107] New: Patron cards: Make barcode width and height scaling editable
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '15

24 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14107 Bug ID: 14107 Summary: Patron cards: Make barcode width and height scaling editable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 14268] New: Change Localsyspref type entry to dropdown
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '15

24 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14268 Bug ID: 14268 Summary: Change Localsyspref type entry to dropdown Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: indradg(a)gmail.com Reporter: indradg(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 14135 The general consensus based on the comment thread of bug 14135 is that it would be better to convert the entry field to a drop-down from the present text input box. -- 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