August 2016 - Koha-bugs - lists.koha-community.org

[Bug 11358] Use Amazon's HTTPS URLs for covers when using HTTPS in Koha.
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11358 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |17137 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17137 [Bug 17137] Omnibus: Always use SSL when referencing external sources -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14571] using_https check for ssl connections doesn' t work in some situations
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14571 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |17137 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17137 [Bug 17137] Omnibus: Always use SSL when referencing external sources -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11297] Add support for custom PQF attributes for Z39.50 server searches
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11297 --- Comment #40 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #39) > Patches still apply - can we rescue this? > > The only left obstacle appears to be a missing unit test. Looking at > comment#38 from David - could this be a possible way? I reckon that method I suggested would be a good test. It would be nice to rescue this one. While I don't think it'll be used by many, it would be good to get it in for the sake of CCSR and anyone else afflicted by this issue (or anyone wanting to customize their queries I suppose). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13414] Enable right truncation with search by relevance
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13414 --- Comment #21 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Fridolin SOMERS from comment #20) > How is this different from enabling "QueryStemming" ? > Automatic truncation can lead to huge number of results, consider the > automatic truncation of author names and short words. That's a good question. I suppose we'd have to look at how QueryStemming works. At a glance, it only adds right truncation if it was able to stem the operand I think. I think Zebra takes care of manually handling "operand*" type queries... So yeah... I don't know about automatic truncation. I think some users expect it, so they might do a query like "au:fish" and expect to get back results for "Fishburne" as well as "Fisher". If you had QueryStemming on, I doubt "fish" would produce a stemmed operand since it's already a stem, so that probably wouldn't work unless you had automatic right truncation. That said, I don't know if that's a good thing... I personally think explicit truncation/wildcarding is a better idea.. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7533] T::T caching during installation
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7533 --- Comment #1 from Mason James <mtj(a)kohaaloha.com> --- (In reply to Paul Poulain from comment #0) > Add an option to the command-line installer that will let the user choose to > activate T::T during installation. Hi Paul, do you think it would be better to enable this feature by default? It seems to good to just have it as an 'optional' choice :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7511] Caching Templates
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '16

30 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7511 Mason James <mtj(a)kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj(a)kohaaloha.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7533] T::T caching during installation
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '16

30 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7533 Mason James <mtj(a)kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj(a)kohaaloha.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17227] New: SQL reserved words should be dis-allowed as branchcodes / authorized values / item types
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '16

30 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17227 Bug ID: 17227 Summary: SQL reserved words should be dis-allowed as branchcodes / authorized values / item types Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 Related to bug 13727 It is possible for the report selectors <<...|branch>> <<...|[authorised value]>> <<...|itemtypes>> ... etc. To insert SQL keywords into the SQL of a report, causing a software error when the report runs, because Koha will now allow SQL reserved words in the queries. To replicate: Create a branch with the branch code 'CREATE' Then create a report using the following query: SELECT * FROM items WHERE items.homebranch = <<Branch|branch>> Run the report, and select the branch with branchcode 'CREATE'. This will cause a software error. There is no way around this (because we *don't* want to allow SQL reserved words to be injected by user input). Therefore we *must* restrict the use of SQL reserved words on branch/authorized value/itemtype creation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14228] fill in patron info by scanning an ID
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '16

30 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14228 jdemuth(a)roseville.ca.us <jdemuth(a)roseville.ca.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdemuth(a)roseville.ca.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11592] opac detail scripts do not respect MARC tag visibility
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '16

30 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11592 --- Comment #142 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- (In reply to M. Tompsett from comment #140) > Comment on attachment 55045 [details] [review] > Bug 11592: (QA followup) Simplify code > > Review of attachment 55045 [details] [review]: > ----------------------------------------------------------------- > > Just an eyeball. > > ::: catalogue/ISBDdetail.pl > @@ -33,5 @@ > > > > =cut > > > > -use strict; > > -#use warnings; FIXME - Bug 2505 > > I wouldn't change to Modern::Perl, unless all the Bug 2505 references are > fixed like this. I prefer to do it, and take responsability if it introduces a warning. Haven't seen one so far. > ::: opac/opac-showmarc.pl > @@ -58,4 @@ > > > > if ($view eq 'card' || $view eq 'html') { > > - # FIXME: GetXmlBiblio needs filtering later. > > - my $xml = $importid ? $record->as_xml(): GetXmlBiblio($biblionumber); > > GetXmlBiblio includes fields which aren't necessarily in GetMarcBiblio, if I > recall correctly. I'm not sure about this. The main difference is that GetMarcBiblio does some sanitization. I think it is safe. This is probably some reminder from the days when everything was done against biblioitems.marc instead of biblioitems.marcxml. -- You are receiving this mail because: You are watching all bug changes.

1 0