[Bug 10466] New: Lists: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 Bug ID: 10466 Summary: Lists: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard@myacpl.org Reporter: dcook@prosentient.com.au This is an old bug that has been spotted again. This time, it's been noticed in the Lists/Virtual Shelves... Basically, itemsloo.size produces different results depending on the type of data that is in the itemsloo hash (within the itemsloop array): 1) If "size" has a value, that value will be printed out. 2) If "size" is null/undef, a seemingly random number will print out. 3) If there is no "size" key in the hash, a seemingly random number will print out. (N.B. In fact, this "random" number is the number of keys in the itemsloo hash. "Size" is a virtual method in the template toolkit. http://www.template-toolkit.org/docs/manual/VMethods.html.) -- Currently, elsewhere in Koha (bug 6374 which covers search.pl, addbooks.pl, opac-search.pl), we're checking to see if a "size" key exists, and if not, we're inserting a "size" key with a value of "". In this case, as long as the SQL query includes the size column, there will always be a "size" key (so scenario 3 is irrelevant). We need to check if "size" is "defined", and if it's not (scenario 2 from above), then we change it to a blank (e.g. "") value, so that it just prints out nothing. The fact that "size" does print a value is probably a bug in TT, so I don't think this is the best long-term solution. It would probably make more sense to rename the variable that we're passing to TT, because if TT gets "fixed" so that "size" always operates as a method rather than fetching the value of a hash, we are going to have to do this all over again. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=6374 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Assignee|oleonard@myacpl.org |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Created attachment 18977 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18977&action=edit Bug 10466 - Lists: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there) Test Plan: Before applying the patch: 0) Make sure you have opac search result XSLT turned off 1) Find bib records that do not have a 300$c (Dimensions) value. 2) Find bib records that do have a 300$c (Dimensions) value. (N.B. These values should be stored in the `size` column of biblioitems). 3) Add items from both sets of records to a List 4) Note that records without a 300$c will display a number at the end of the "Publication" description/string. It should be something like 33 or 34 in most cases. 5) Note that records with a 300$c don't display this number. They just show the value from 300$c. Apply the patch. 6) Clear your cache, refresh the page, etc. 7) Note that the number (e.g. 33 or 34) has disappeared from the end of the "Publication" description/string. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #2 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- I do remember this bug. Do not know where it was. But I think there was code that forces the size value to be there. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 --- Comment #3 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Wow. So much words for one line :) Compliments for such a detailed test plan and even for finding such a small bug. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18977|0 |1 is obsolete| | --- Comment #4 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 18980 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18980&action=edit Bug 10466 - Lists: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there) This patch checks to see if "size" is undefined. If it is, we add a blank (i.e. "") value to it in place of undef. If we do not do this, calling "itemloo.size" will return the size of the "itemloo" hash, rather than the value for the "size" key. This is because "size" is a virtual method in Template Toolkit. It's uncertain why the value is retrieved for the "size" key when there is a defined value and why TT doesn't use the method instead, and that it uses "size" as a method only if there is either no "size" key or if the value tied to the "size" key is null/undef. This might be a feature or it might be a bug in TT... In the mean-time, we will check to see if it's undefined. If it is, we'll give it a value. This bug has been identified in the opac-search.pl, search.pl and addbooks.pl pages before. To address it, we're currently checking if there is a "size" key, and if not...we're adding one with a blank value. This patch takes up that same idea, although I think it might be better to rename the variable before passing it to TT in case the behaviour of TT changes in the future in regards to how it handles virtual methods. N.B. Obviously, this only affects users not using XSLTs. -- Test Plan: Before applying the patch: 0) Make sure you have opac search result XSLT turned off 1) Find bib records that do not have a 300$c (Dimensions) value. 2) Find bib records that do have a 300$c (Dimensions) value. (N.B. These values should be stored in the `size` column of biblioitems). 3) Add items from both sets of records to a List 4) Note that records without a 300$c will display a number at the end of the "Publication" description/string. It should be something like 33 or 34 in most cases. 5) Note that records with a 300$c don't display this number. They just show the value from 300$c. Apply the patch. 6) Clear your cache, refresh the page, etc. 7) Note that the number (e.g. 33 or 34) has disappeared from the end of the "Publication" description/string. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Added a small comment at the end of this one line. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #5 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- QA Comment: One line patch fixes a small problem. Altough we could indeed solve this problem even better by replacing size with something else, this fix deserves to be pushed if it were only for the commit message and test plan :) Additionally, there is at least one other place where this same problem is also solved in this same way (and was pushed before..) Note that I took the liberty to amend with a small comment at the end of your line about the reason you explained so thoroughly in the commit message. Passed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master CC| |gmcharlt@gmail.com --- Comment #6 from Galen Charlton <gmcharlt@gmail.com> --- I've pushed this to master. I updated the commit message to clarify to normal users the problem being corrected. Yes, I fully realize that this has made the commit message EVEN LONGER! :) Thanks, David, especially for taking the time to fully describe your thinking on this. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable CC| |tomascohen@gmail.com --- Comment #7 from Tomás Cohen Arazi <tomascohen@gmail.com> --- This patch has been pushed to 3.12.x, will be in 3.12.2. Thanks David! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bgkriegel@gmail.com --- Comment #8 from Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> --- Pushed to 3.10.x, will be in 3.10.8 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 Chris Hall <chrish@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chrish@catalyst.net.nz --- Comment #9 from Chris Hall <chrish@catalyst.net.nz> --- Pushed to 3.8.x, will be in 3.8.15 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10466 Fridolin SOMERS <fridolyn.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11357 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org