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

[Bug 14797] Cancelling orders with no alert to existing holds
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14797 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15330] Allow to search for late orders by budget and fund
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15330 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15348] Change/Edit estimated delivery date per order line
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15348 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15342] Performance 3.22 - Omnibus
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15342 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl --- Comment #2 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- >From the mailing list: Bug 16041 is in 3.22.7 and could help for search results. Bug 15263 as well. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10855] Custom fields for subscriptions
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10855 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |16565 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16565 [Bug 16565] additional_fields and additional_field_values are not dropped in kohastructure.sql -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13669] Web installer fails to load sample data on MySQL 5.6+
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13669 --- Comment #50 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Bernardo Gonzalez Kriegel from comment #49) > Errors are not in the procedeure, I tested extensively but on msyql < 5.6, > so this is specific to ver 5.6+ treatment of SQL, or 5.7 more specifically > > 1) table: auth_subfield_structure > > line: 72 `defaultvalue` TEXT DEFAULT '', > error: (BLOB, TEXT, GEOMETRY or JSON column 'defaultvalue' can't have a > default value): CREATE TABLE `auth_subfield_structure` > > Seems that we can't have default values here. > > Ref: http://dev.mysql.com/doc/refman/5.7/en/blob.html > ->" BLOB and TEXT columns cannot have DEFAULT values." I get this one using --show-warnings on MariaDB 10.0.24 Fixed with diff --git a/installer/data/mysql/kohastructure.sql b/installer/data/mysql/kohastructure.sql index 42bff46..ea220bb 100644 --- a/installer/data/mysql/kohastructure.sql +++ b/installer/data/mysql/kohastructure.sql @@ -69,7 +69,7 @@ CREATE TABLE `auth_subfield_structure` ( `linkid` tinyint(1) NOT NULL default 0, `kohafield` varchar(45) NULL default '', `frameworkcode` varchar(10) NOT NULL default '', - `defaultvalue` TEXT DEFAULT '', + `defaultvalue` TEXT, But I don't get the others > MySQL 5.7 does not like things like that. > Perhaps we can change the sql_mode for Koha globally, > or fix all the sample data (not difficult) in all languages, > and test/sign/QA everything... before release? Yes, on another bug report. Now you have Ubuntu 16.04, could you please submit a patch? :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15541] Prevent normalization during matching/import process
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 --- Comment #18 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to David Cook from comment #16) > When I run "prove t/db_dependent/Search.t", it says that all tests are > successful, although there are lots of warnings generated. Between April 15 and May 23 some things may have changed :) > > [2] The source_normalizer or norms just lead me to two FIXMEs: > > # FIXME normalize, substr > > # FIXME - default normalizer > These FIXME messages pre-date my patch. True. But that is obviously not my point. Although Matcher.pm has some code around norms and normalizer, actually it is just uncompleted functionality. The code just calls a simple _normalized routine. The "references to normalization subroutines (under C4::Normalize) to be applied to the source string" are not used and do not exist. > I'm open to removing _normalize() from the matching completely. Honestly, I > figured that the community would be against it, so I created a way of opting > out of the default _normalize(). That way default system behaviour doesn't > change, while some people will know how to deactivate it. I am not suggesting to remove it. As noted above, I would be hesitant to make certain changes in uncompleted functionality. > > [3] I have some doubts about this new condition: > > if ($QParser && $matchpoint->{'index'} !~ m/\w,\w/) { > > Somehow you managed to bump in another unfinished area here too :) > > I would rather leave the condition as it was. In the QParser branch you > > could choose to ignore/remove the second specifier word with a similar regex. > It's not really a new condition. If you look at C4::Search::SimpleSearch, > you'll see that it's already there: Good point. Leave it there. > Can the QA team indicate how to proceed? Could you (slightly) adjust the way to skip the normalize call for the URLs, that does not suggest that the norms functionality is present while we do not even have C4::Normalizer? Maybe Jonathan wants to jump in too and add comments? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10756] Carousel Display of New Titles on OPAC home page
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10756 --- Comment #22 from Mason James <mtj(a)kohaaloha.com> --- (In reply to Jonathan Druart from comment #21) > (In reply to Mason James from comment #20) > > (In reply to Jonathan Druart from comment #17) > > > (In reply to Marcel de Rooy from comment #13) > > > > On http://www.jacksasylum.eu/ContentFlow/ I only see changelogs until 2010? > > > > If there is no further development(?), this might be a risk. > > > > > > I can see that as blocker, Mason, would it be easy to update the plugin you > > > used? > > > > Jonathan, can you please suggest a replacement for ContentFlow, so I may > > proceed > > I have no idea, but reading the previous comment it seems that jcarousel or > jquery-flipster could be good candidates. > Kyle, any ideas? my humble opinion is that aesthetically flipster is a better choice for the style of this feature -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15541] Prevent normalization during matching/import process
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #17 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Marcel de Rooy from comment #11) > [1] Although your changes in SimpleSearch are very small, it would probably > help if you would add a test case in t/db_dependent/Search.t. (It seems to > fail some tests currently, separate from your patch.) I've reviewed Matcher.pm and Search.pm, an I don't think it would be possible to add a test case. The functions aren't atomic enough. The altered behaviour is internal to the functions and thus I don't see any way to automatically test it. Changing status back to Signed Off. Happy to discuss further or implement changes where necessary. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15541] Prevent normalization during matching/import process
by bugzilla-daemon＠bugs.koha-community.org 23 May '16

23 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|Academy | --- Comment #16 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Marcel de Rooy from comment #11) > [1] Although your changes in SimpleSearch are very small, it would probably > help if you would add a test case in t/db_dependent/Search.t. (It seems to > fail some tests currently, separate from your patch.) When I run "prove t/db_dependent/Search.t", it says that all tests are successful, although there are lots of warnings generated. I'll review the test code to see if I can add a test... > [2] The source_normalizer or norms just lead me to two FIXMEs: > # FIXME normalize, substr > # FIXME - default normalizer These FIXME messages pre-date my patch. > You introduce none and raw in the regex while this field actually does > nothing (and should not have been there in this stage). I don't understand this sentence. > Your patch starts > using this field, while the only thing you want is not running _normalize > for (mainly?) URLs. URLs are certainly the main thing I want to not normalize, but honestly nothing should be normalized during the matching, as Zebra already handles normalization for search queries. > If we do not really solve the problem of this unused > field, I think we should not touch it. BTW What would be the difference > between raw and none? The regex suggests more than what we offer. There is no difference between raw and none. They're just synonyms. I'm open to removing _normalize() from the matching completely. Honestly, I figured that the community would be against it, so I created a way of opting out of the default _normalize(). That way default system behaviour doesn't change, while some people will know how to deactivate it. > [3] I have some doubts about this new condition: > if ($QParser && $matchpoint->{'index'} !~ m/\w,\w/) { > Somehow you managed to bump in another unfinished area here too :) > I would rather leave the condition as it was. In the QParser branch you > could choose to ignore/remove the second specifier word with a similar regex. > It's not really a new condition. If you look at C4::Search::SimpleSearch, you'll see that it's already there: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); Also, you can't remove the second specifier word, because it's essential to the query. You also can't ignore it, because the QParser can't handle it. That's why I added the same condition that's found in C4::Search::SimpleSearch. You need to catch this condition before going into the QParser code block. -- Can the QA team indicate how to proceed? I'll look at adding a unit test. However, the QParser condition or one similar to it needs to stay. As for _normalize(), I'll remove it completely, if that's a change which will be accepted by the QA team and the RM. -- You are receiving this mail because: You are watching all bug changes.

1 0