http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12371 --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- While I agree your solution would work, I think this one is better because it solves it at the root of the problem. Fixing the issue at the opacmemberentry.pl level would make it easier to introduce regressions in the future. Thanks for the input though! (In reply to Nick Clemens from comment #7)
It is possible I am wrong, but I couldn't recreate the problem in testing.
Looking at the code that dmin mentions it appears that opac-memberentry.pl passes two variables to the sql query in Letters.pm
It appears that the function in Letters.pm was designed to allow for general use in pulling from 'borrower_modifications' using either borrowernumber or verification_token.
When trying to pull data by verification_token, opacmemberentry.pl passes the verification_token for both variables (borrowernumber compare and verification_token compare)
In my testing, when mysql gets a string as a variable to compare to an integer (borrowernumber) it will just take the first integer and chop the rest of the string, meaning any verification_token that beings with zero will compare successfully to borrowernumber zero
It should be possible to leave the original sql in Letters.pm and just replace the first variable passed from opacmemberentry.pl from verification_token to 'a' to prevent matching to zero and to force a comparison of the tokens.
-- You are receiving this mail because: You are watching all bug changes.