The syspref Reference_NFL_Statuses was requested but I don't know what to say; this indicates that the test requires updating at t/db_dependent/Search.t line 197.
Created attachment 122312 [details] [review] Bug 28483: Avoid useless warnings There are too many warnings about uninitialized variables in Search.pm. This patch deals with that, the same way it is dealt accross the file: by setting an empty string when things are not defined. To test: 1. Run: $ kshell k$ prove t/db_dependent/Search.t => FAIL: Wow, too many warnings. Some related to this bug, some not. 2. Apply this patch 3. Repeat 1 => SUCCESS: No more warnings! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 122313 [details] [review] Bug 28483: Remove warnings from Search.t There are too many warnings about uninitialized variables in Search.pm. This patch deals with that, the same way it is dealt accross the file: by setting an empty string when things are not defined. To test: 1. Run: $ kshell k$ prove t/db_dependent/Search.t => FAIL: Wow, too many warnings. Some related to this bug, some not. 2. Apply this patch 3. Repeat 1 => SUCCESS: No more warnings! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When seeing this, I wonder right away why not the other one? - my $query = $operands[0]; + my $query = $operands[0] // ""; my $simple_query = $operands[0]; And looking a bit later, I see: for ($query_cgi,$simple_query) { s/"//g; } Shouldnt this trigger a warn too when undefined?
Created attachment 122740 [details] [review] Bug 28483: Remove warnings from Search.t There are too many warnings about uninitialized variables in Search.pm. This patch deals with that, the same way it is dealt accross the file: by setting an empty string when things are not defined. To test: 1. Run: $ kshell k$ prove t/db_dependent/Search.t => FAIL: Wow, too many warnings. Some related to this bug, some not. 2. Apply this patch 3. Repeat 1 => SUCCESS: No more warnings! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Marcel de Rooy from comment #3) > When seeing this, I wonder right away why not the other one? > > - my $query = $operands[0]; > + my $query = $operands[0] // ""; > my $simple_query = $operands[0]; > > And looking a bit later, I see: > for ($query_cgi,$simple_query) { > s/"//g; > } > Shouldnt this trigger a warn too when undefined? The code sets it undef later, and simple_query is not used between the two places
(In reply to Nick Clemens from comment #5) > (In reply to Marcel de Rooy from comment #3) > > When seeing this, I wonder right away why not the other one? > > > > - my $query = $operands[0]; > > + my $query = $operands[0] // ""; > > my $simple_query = $operands[0]; > > > > And looking a bit later, I see: > > for ($query_cgi,$simple_query) { > > s/"//g; > > } > > Shouldnt this trigger a warn too when undefined? > > The code sets it undef later, and simple_query is not used between the two > places Hmm. Not important but I do not see that it is set to undef later, and if it is, then it will surely trigger the uninitialized warn that we want to resolve. If it is not set, then it depends on $operands[0]
Pushed to master for 21.11, thanks to everybody involved!
Created attachment 122794 [details] [review] Bug 28483: Fix t/Search/buildQuery.t
Follow-up pushed to master.
Pushed to 21.05.x for 21.05.02
Depends on Bug 21260 not in 20.11.x