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

[Bug 13715] "limit to items available" hides records with multiple items where 1 is not available (checked out) but others are
by bugzilla-daemon＠bugs.koha-community.org 05 May '16

05 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13715 Janet McGowan <janet.mcgowan(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janet.mcgowan(a)ptfs-europe.c | |om -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12669] "Template process failed: undef error - Invalid local time for date in time zone"
by bugzilla-daemon＠bugs.koha-community.org 05 May '16

05 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12669 --- Comment #35 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Colin Campbell from comment #33) > I wonder if we could use utc internally and just use the local timezone to > convert user input and to present the date externally. We'd need to be > fairly vigorous in cleaning up the various vaguely different ways we > currently treat dates, cetainly when we're doing calculations we probably > want to do them in a common base as otherwise there's too many opportunities > to fall into a given timezone's black hole Agreed. I think we could use UTC internally and just use the local timezone to convert user input and convert output for users. We would need to be vigorous in cleaning up how we've currently treating dates though, yeah :/. Generally speaking, we're not recording super precise datetime data, so I don't see why we couldn't use floating timezones for calculations. I suppose it depends on the calculations being done, but that's really the only way of doing it with our current holiday checking code without causing invalid local times. We might be able to use UTC for some calculations, but... I don't think so in the holiday case because we'd be interested in local days and obviously UTC doesn't always correspond with the same day. You might have 2 UTC timestamps for the same day in UTC, but they'd actually correspond to different days in local time. If you truncated that for the sake of date checking, you'd be skipping one of the local days, which would be really bad. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12669] "Template process failed: undef error - Invalid local time for date in time zone"
by bugzilla-daemon＠bugs.koha-community.org 05 May '16

05 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12669 --- Comment #34 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Marcel de Rooy from comment #32) > David: I recall falling back to floating timezone for making calculations > with far future dates like an expiry in 9999 or so. > If you would use a normal timezone, you will have major performance issues. Yeah, that's an unrelated issue I believe. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15434] Make search results breadcrumbs human readable
by bugzilla-daemon＠bugs.koha-community.org 05 May '16

05 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15434 --- Comment #35 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Srdjan Jankovic from comment #34) > I could have done it both ways, but these days I prefer client side. > * As a sever side dude, I prefer that clients use their cycles I think client capabilities really range a lot, so as a server side dude I'd rather present as consistent a baseline as possible. > * Tomorrow we decide to make search an api call, this still works > Your API call would still need to return the text for you to replace, so that doesn't really make sense. The API call could return translated text. You'd just need a locale parameter. > And a personal, not a valid reason: I find that translations are easier > (cleaner) in js I haven't done much with translations, but I believe you with that one. That said, if we used resource files for certain strings as I've suggested elsewhere, translations would be simple. In a persistent environment, you only load the file once, so there's not much overhead. But that's just my 2 cents. I'm not offering up any alternative patches, so I'm mostly just curious about the rationale. Thanks for taking the time to respond :). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15434] Make search results breadcrumbs human readable
by bugzilla-daemon＠bugs.koha-community.org 05 May '16

05 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15434 --- Comment #34 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> --- > We build the breadcrumbs... so why are we doing this client-side? Why aren't > we doing this server-side? I could have done it both ways, but these days I prefer client side. * As a sever side dude, I prefer that clients use their cycles * Tomorrow we decide to make search an api call, this still works And a personal, not a valid reason: I find that translations are easier (cleaner) in js -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12478] Elasticsearch support for Koha
by bugzilla-daemon＠bugs.koha-community.org 05 May '16

05 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478 --- Comment #245 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> --- Also, with my version of elastic, I had to do following changes: diff --git a/Koha/ElasticSearch.pm b/Koha/ElasticSearch.pm index d56c344..22bc064 100644 --- a/Koha/ElasticSearch.pm +++ b/Koha/ElasticSearch.pm @@ -171,11 +171,6 @@ sub get_elasticsearch_mappings { include_in_all => JSON::false, type => "string", }, - '_all.phrase' => { - search_analyzer => "analyser_phrase", - index_analyzer => "analyser_phrase", - type => "string", - }, } } }; @@ -195,15 +190,12 @@ sub get_elasticsearch_mappings { ? 'boolean' : 'string'; $mappings->{data}{properties}{$name} = { - search_analyzer => "analyser_standard", - index_analyzer => "analyser_standard", + analyzer => "analyser_standard", type => $es_type, fields => { phrase => { - search_analyzer => "analyser_phrase", - index_analyzer => "analyser_phrase", + analyzer => "analyser_phrase", type => "string", - copy_to => "_all.phrase", }, raw => { "type" => "string", @@ -222,22 +214,19 @@ sub get_elasticsearch_mappings { if ($suggestible) { $mappings->{data}{properties}{ $name . '__suggestion' } = { type => 'completion', - index_analyzer => 'simple', - search_analyzer => 'simple', + analyzer => 'simple', }; } # Sort may be true, false, or undef. Here we care if it's # anything other than undef. if (defined $sort) { $mappings->{data}{properties}{ $name . '__sort' } = { - search_analyzer => "analyser_phrase", - index_analyzer => "analyser_phrase", + analyzer => "analyser_phrase", type => "string", include_in_all => JSON::false, fields => { phrase => { - search_analyzer => "analyser_phrase", - index_analyzer => "analyser_phrase", + analyzer => "analyser_phrase", type => "string", }, }, diff --git a/installer/data/mysql/updatedatabase.pl b/installer/data/mysql/updatedatabase.pl index 9e6d390..e092704 100755 --- a/installer/data/mysql/updatedatabase.pl +++ b/installer/data/mysql/updatedatabase.pl @@ -12332,13 +12332,13 @@ my $indexes = LoadFile( $mappings_yaml ); while ( my ( $index_name, $fields ) = each %$indexes ) { while ( my ( $field_name, $data ) = each %$fields ) { - my $field_type = $data->{type}; + my $field_type = $data->{type} || 'string'; my $field_label = $data->{label}; my $mappings = $data->{mappings}; my $search_field = Koha::SearchFields->find_or_create({ name => $field_name, label => $field_label, type => $field_type }, { key => 'name' }); for my $mapping ( @$mappings ) { my $marc_field = Koha::SearchMarcMaps->find_or_create({ index_name => $index_name, marc_type => $mapping->{marc_type}, marc_field => $mapping->{marc_field} }); - $search_field->add_to_search_marc_maps($marc_field, { facet => $mapping->{facet}, suggestible => $mapping->{suggestible}, sort => $mapping->{sort} } ); + $search_field->add_to_search_marc_maps($marc_field, { facet => $mapping->{facet} || 0, suggestible => $mapping->{suggestible} || 0, sort => $mapping->{sort} || undef } ); } } } -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7976] "Borrow Permission" is not used and can be removed
by bugzilla-daemon＠bugs.koha-community.org 04 May '16

04 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7976 Bouzid <bouzid.fergani(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |bouzid.fergani(a)inlibro.com Resolution|FIXED |--- --- Comment #14 from Bouzid <bouzid.fergani(a)inlibro.com> --- Hi all, The borrow permission is removed, but it existing in this files: opac/opac-idref.pl:40: flagsrequired => { borrow => 1 }, opac/opac-news-rss.pl:37: flagsrequired => { borrow => 1 }, opac/opac-restrictedpage.pl:43: flagsrequired => { borrow => 1 }, opac/svc/login:46 checkauth( $query, 1, { borrow => 1 }, 'opac', $decoded_json->{'email'} ); I think, it's a bug. Bouzid. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12478] Elasticsearch support for Koha
by bugzilla-daemon＠bugs.koha-community.org 04 May '16

04 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |16445 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16445 [Bug 16445] Bug 12478 has added an unnecessary line to Koha/Database.pm -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15333] Use Koha::Cache for caching all holidays
by bugzilla-daemon＠bugs.koha-community.org 04 May '16

04 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15333 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |7172 CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org Assignee|gmcharlt(a)gmail.com |jonathan.druart(a)bugs.koha-c | |ommunity.org --- Comment #4 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Note that we won't add any performance gain with this patch (on the contrary), but at least we will get rid of possible weird behaviors. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7172 [Bug 7172] Omnibus for Plack variable scoping problems -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7172] Omnibus for Plack variable scoping problems
by bugzilla-daemon＠bugs.koha-community.org 04 May '16

04 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7172 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |15333 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15333 [Bug 15333] Use Koha::Cache for caching all holidays -- You are receiving this mail because: You are watching all bug changes.

1 0