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

[Bug 13427] New: jQuery Timepicker is not translated on returns page
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13427 Bug ID: 13427 Summary: jQuery Timepicker is not translated on returns page Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Created attachment 34266 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=34266&action=edit Timepicker on returns page In circulation module on checkin page (/cgi-bin/koha/circ/returns.pl), the timepicker for setting the return date/time is not fully translatable, as I understand (according to bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11618) there is missing line [% INCLUDE 'timepicker.inc' %] in returns.tt template file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 11467] New: Untranslatable strings in opac-detail.tt
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11467 Bug ID: 11467 Summary: Untranslatable strings in opac-detail.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Some strings in Javascript are not properly formatted for translation: $(".title").append('<a href="'+json.book.detail_link+'" id="idreambooksreadometer"><img src="http://idreambooks.com/remotereadometer/'+isbn+'.jpg" alt="'+json.book.title+' by '+json.book.author+'" title="Rating based on reviews of '+json.book.title+'"></a>'); $("#catalogue_detail_biblio").append("<span class='idreambookssummary results_summary'><a href='"+json.book.detail_link+"'><img src='"+json.book.to_read_or_not_small+"' alt='"+json.book.title+" by "+json.book.author+"' title='Rating based on reviews of "+json.book.title+"'>"+json.book.rating+"%</a> <a href='http://www.idreambooks.com/'>rating based on reviews at iDreamBooks.com</a></span>"); if (arrPagination[i].author) html += "<br /> by " + arrPagination[i].author; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 11011] New: rephrase "in keyword" in OPAC authority search
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11011 Bug ID: 11011 Summary: rephrase "in keyword" in OPAC authority search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mathieu.saby(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org In OPAC authority search, you can choose to search "in keyword". I am not fluent in english but I find this wording awkward (and the french translation too, of course) M. Saby -- You are receiving this mail because: You are watching all bug changes.

1 16

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