https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Assignee|koha-bugs@lists.koha-commun |philippe.blouin@inlibro.com |ity.org | Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Patch still applies, but missing test plan and unit test. Blou, do you still intend to work on this one or shoudl we reset to NEW? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.blouin@inlibro.com | |, shi-yao.wang@inLibro.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 Shi Yao Wang <shi-yao.wang@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #131170|0 |1 is obsolete| | --- Comment #5 from Shi Yao Wang <shi-yao.wang@inLibro.com> --- Created attachment 136656 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=136656&action=edit Bug 30196: Odd number of elements warning caused by dt_from_string Koha/DateUtils' dt_from_string is a sub expected to return a scalar, but does not in all case. In one instance, tt simply return... nothing, which cause one common call output_pref( { dt => dt_from_string( $serinfo->{$d} ), dateonly => 1 } ); to output a warning. Simply returning undef instead will solve the issue. Test plan: 1- Have a terminal tail intranet error logs 2- In the code, go to about.pl and change the only dt_from_string() to dt_from_string('0000-00-00') 3- Go to About Koha 4- Notice the logs output is: "Odd number of elements in anonymous hash at ..." and error 500 on the page. 5- Apply the patch 6- Redo step 3 and notice the previous log output is not there and the page loads 7- run `prove t/DateUtils.t` and all tests should pass -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com --- Comment #7 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Instead use: output_pref({ str => $serinfo->{$d}, dateonly => 1 }) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 --- Comment #9 from Blou <philippe.blouin@inlibro.com> --- Which relate to https://metacpan.org/pod/Perl::Critic::Policy::Subroutines::ProhibitExplicit... which I find the explanation funny. Yes, you might screw up boolean tests with returning an undef. But this bug here demonstrate you can screw up hash creation. Anyway, I have no problem using a standard. But your solution avoids the problem while not fixing it. Aren't you afraid somewhere someone will use it again the same way ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30196 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|Failed QA |RESOLVED --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #10)

We are trying to pass perlcritic, and it's a good idea to stick to it. We can easily workaround it, either using 'str' instead of 'dt' or adding 'scalar' to force the context.

I wouldn't bother fixing this bug because: * There is bug 30718, and it would be way more interesting to work on it, and it should fix/remove most of the occurrences. * You shouldn't have 0000-00-00 dates anymore in your DB (how did it happen?). This is a bug or a config issue on itself.

I stopped being afraid of Koha code, I sleep better now :D

Moving to WONTFIX a per Joubu's comment and the fact that 30718 is now fixed. Please reopen if you disagree! -- You are receiving this mail because: You are watching all bug changes.