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

[Bug 8686] New: author search in staff missing checkboxes and menu
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8686 Priority: P5 - low Change sponsored?: --- Bug ID: 8686 Assignee: oleonard(a)myacpl.org Summary: author search in staff missing checkboxes and menu Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com URL: cgi-bin/koha/catalogue/search.pl?q=au:%22Engard,%20Nic ole%20C.,%22 Hardware: All Status: NEW Version: master Component: Templates Product: Koha Created attachment 11825 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=11825&action=edit author search The menu bar that lets you put things in lists and such at the top of the results in the staff client goes away - along with the check boxes when you do an author search. See attached. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 11941] New: "Patron list"s are not accessible from the HTML header "More" -> "Lists"
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11941 Bug ID: 11941 Summary: "Patron list"s are not accessible from the HTML header "More" -> "Lists" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Existing list functionality is accessible from there. Why have a separate way to handle Patron lists and Record lists? To preserve the excellent usability of Koha I find all list related features should be present under "More" -> "Lists" -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 10355] New: Second click on modification log misses object parameter
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10355 Bug ID: 10355 Summary: Second click on modification log misses object parameter Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de To reproduce the problem: 1) Go to any detail page in staff 2) Click on the modification log tab 3) Verify, that the object is prefilled with the records biblionumber and you can also see it as parameter in the url 4) Click a second time on modification log to reset your search 4) Verify that the url is missing the biblionumber now -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 11790] New: C4::Charset should not depend on C4::Context
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11790 Bug ID: 11790 Summary: C4::Charset should not depend on C4::Context Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The patch for bug 8437 added a system preference lookup to C4::Charset::SetMarcUnicodeFlag(), which in turn forces a dependency on C4::Context (c.f. bug 11730). This is a bit of a wart, as there's nothing else in C4::Charset that is dependent on there being a Koha database. It builds on yet another wart, introduced by commit 7eca37db, that overloads SetMarcUnicodeFlag() to set fields in the UNIMARC 100 that have nothing to do with the character encoding. This should be split apart so that - C4::Charset doesn't require a dependency on C4::Context - code that handles anything beyond setting the character set flags is moved out of SetMarcUnicodeFlag -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 13908] New: Checkouts table sorting is not honoring default sort preferences
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13908 Bug ID: 13908 Summary: Checkouts table sorting is not honoring default sort preferences 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The checkouts table no longer honors the system preferences todaysIssuesDefaultSortOrder and previousIssuesDefaultSortOrder. This causes much frustration for librarians who prefer a different sort order. In particular, many librarians prefer to see the oldest previous issues at the top of the list so those overdue items are visible "above the fold". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 12066] New: renewals not tracking branch in stats
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12066 Bug ID: 12066 Summary: renewals not tracking branch in stats Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The OpacRenewalBranch is set to renew at the library the item was checked out, but it seem that all renewals are being recorded as NULL. mysql> select count(*) from statistics where branch is null; +----------+ | count(*) | +----------+ | 457 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from statistics where type='renew' and branch is null; +----------+ | count(*) | +----------+ | 457 | +----------+ 1 row in set (0.03 sec) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[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 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