$ git grep '\->param' | grep -v -e 'template' -e 'multi_param' | grep '@' | wc -l 54
Created attachment 128908 [details] [review] Bug 29771: Remove warning from acqui/finishreceive.pl This patch removes a warning that shows when receiving. To test: 1. Do the acq workflow up to the receive step. 2. Once you choose the items and click on Finish => FAIL: There's a warning in the logs 3. Revert receipt 4. Apply this patch 5. Receive => SUCCESS: No more warnings 6. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 128909 [details] [review] Bug 29771: Remove trivial cases I squashed the patches because they are too trivial to have a test plan. Or it is too much work to write the test plan for such trivial cases. I leave the original commit messages just in case. Generally, this are all cases in which CGI::param is being called in a trivially identifiable _list context_. i.e. they are assigned to a @variable. I left one case out on purpose: admin/auth_subfields_structure.pl Paul introduced this: my @kohafield = ''.$input->param('kohafield'); and then: my $kohafield = $kohafield[$i]; My intuition says it is forcing scalar context on the first assignment so the list contains a single element and then inside the loop some $kohafield assignments should lead to undef, and even warnings. I leave it for a separate patch because it is not that easy testable and is a sensible area. Bug 29771: Remove warning from acqui/finishreceive.pl This patch removes a warning that shows when receiving. To test: 1. Do the acq workflow up to the receive step. 2. Once you choose the items and click on Finish => FAIL: There's a warning in the logs 3. Revert receipt 4. Apply this patch 5. Receive => SUCCESS: No more warnings 6. Sign off :-D Bug 29771: Remove warning from svc/members/add_to_list To test: 1. Run: $ tail -f /var/log/koha/kohadev/*-error.log 2. Generate a patron list 3. Perform a patron search that gives you a few 4. Select some, and choose to add them to the list => FAIL: The logs show the infamous warn: CGI::param called in list context from /kohadevbox/koha/svc/members/add_to_list 5. Apply this patch 6. Restart plack and repeat 4 => SUCCESS: No warn! 7. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 128910 [details] [review] Bug 29771: Scalar context for split This patch tackles a very specific scenario. Calling split(..., CGI::param) makes it be called in list context. The split docs say: split /PATTERN/,EXPR,LIMIT this means the first CGI param will be used as EXPR and the second one as LIMIT, which is wrong anyway. So the fix is to just force scalar context. To test: 1. Not sure, just make sure nothing breaks when using the scripts in the browser. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 131129 [details] [review] Bug 29771: Remove trivial cases I squashed the patches because they are too trivial to have a test plan. Or it is too much work to write the test plan for such trivial cases. I leave the original commit messages just in case. Generally, this are all cases in which CGI::param is being called in a trivially identifiable _list context_. i.e. they are assigned to a @variable. I left one case out on purpose: admin/auth_subfields_structure.pl Paul introduced this: my @kohafield = ''.$input->param('kohafield'); and then: my $kohafield = $kohafield[$i]; My intuition says it is forcing scalar context on the first assignment so the list contains a single element and then inside the loop some $kohafield assignments should lead to undef, and even warnings. I leave it for a separate patch because it is not that easy testable and is a sensible area. Bug 29771: Remove warning from acqui/finishreceive.pl This patch removes a warning that shows when receiving. To test: 1. Do the acq workflow up to the receive step. 2. Once you choose the items and click on Finish => FAIL: There's a warning in the logs 3. Revert receipt 4. Apply this patch 5. Receive => SUCCESS: No more warnings 6. Sign off :-D Bug 29771: Remove warning from svc/members/add_to_list To test: 1. Run: $ tail -f /var/log/koha/kohadev/*-error.log 2. Generate a patron list 3. Perform a patron search that gives you a few 4. Select some, and choose to add them to the list => FAIL: The logs show the infamous warn: CGI::param called in list context from /kohadevbox/koha/svc/members/add_to_list 5. Apply this patch 6. Restart plack and repeat 4 => SUCCESS: No warn! 7. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 131130 [details] [review] Bug 29771: Scalar context for split This patch tackles a very specific scenario. Calling split(..., CGI::param) makes it be called in list context. The split docs say: split /PATTERN/,EXPR,LIMIT this means the first CGI param will be used as EXPR and the second one as LIMIT, which is wrong anyway. So the fix is to just force scalar context. To test: 1. Not sure, just make sure nothing breaks when using the scripts in the browser. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 131187 [details] [review] Bug 29771: Remove trivial cases I squashed the patches because they are too trivial to have a test plan. Or it is too much work to write the test plan for such trivial cases. I leave the original commit messages just in case. Generally, this are all cases in which CGI::param is being called in a trivially identifiable _list context_. i.e. they are assigned to a @variable. I left one case out on purpose: admin/auth_subfields_structure.pl Paul introduced this: my @kohafield = ''.$input->param('kohafield'); and then: my $kohafield = $kohafield[$i]; My intuition says it is forcing scalar context on the first assignment so the list contains a single element and then inside the loop some $kohafield assignments should lead to undef, and even warnings. I leave it for a separate patch because it is not that easy testable and is a sensible area. Bug 29771: Remove warning from acqui/finishreceive.pl This patch removes a warning that shows when receiving. To test: 1. Do the acq workflow up to the receive step. 2. Once you choose the items and click on Finish => FAIL: There's a warning in the logs 3. Revert receipt 4. Apply this patch 5. Receive => SUCCESS: No more warnings 6. Sign off :-D Bug 29771: Remove warning from svc/members/add_to_list To test: 1. Run: $ tail -f /var/log/koha/kohadev/*-error.log 2. Generate a patron list 3. Perform a patron search that gives you a few 4. Select some, and choose to add them to the list => FAIL: The logs show the infamous warn: CGI::param called in list context from /kohadevbox/koha/svc/members/add_to_list 5. Apply this patch 6. Restart plack and repeat 4 => SUCCESS: No warn! 7. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 131188 [details] [review] Bug 29771: Scalar context for split This patch tackles a very specific scenario. Calling split(..., CGI::param) makes it be called in list context. The split docs say: split /PATTERN/,EXPR,LIMIT this means the first CGI param will be used as EXPR and the second one as LIMIT, which is wrong anyway. So the fix is to just force scalar context. To test: 1. Not sure, just make sure nothing breaks when using the scripts in the browser. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Great call! This fixes all obvious cases and many non-obvious ones too.. No regressions found, lets get this pushed and deal with any further occurrences as we spot them. It would be nice to have a QA script test catch new introductions of such warnings.. but that can be handled outside of this bug. Passing QA
Dependency with Bug 17239 ? isn't it the opposite relation ?
(In reply to Fridolin Somers from comment #10) > Dependency with Bug 17239 ? isn't it the opposite relation ? I think it is wrong. Probably a duplicate instead
(In reply to Tomás Cohen Arazi from comment #11) > (In reply to Fridolin Somers from comment #10) > > Dependency with Bug 17239 ? isn't it the opposite relation ? > > I think it is wrong. Probably a duplicate instead OK I move to See Also
Pushed to master for 22.05, thanks to everybody involved [U+1F984]
Pushed to 21.11.x for 21.11.04
Pushed to 21.05.x for 21.05.14
Not backported to oldoldstable (20.11.x). Feel free to ask if it's needed.