Summary: | AutoMemberNum fails on very large cardnumbers | ||
---|---|---|---|
Product: | Koha | Reporter: | Andrew Fuerste-Henry <andrewfh> |
Component: | Patrons | Assignee: | Bugs List <koha-bugs> |
Status: | Failed QA --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | bwsdonna, FernandoM, gmcharlt, jonathan.druart, kyle.m.hall, kyle, nick |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8533 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: |
Bug 26035: Add tests to highlight the problem
Bug 26035: AutoMemberNum should support cardnumbers up to 32 characters Bug 26035: AutoMemberNum should support cardnumbers up to 32 characters |
Description
Andrew Fuerste-Henry
2020-07-21 21:36:29 UTC
Previous comment describes the behavior I'm seeing on a partner site on 19.11. On my test site, on both master and 19.11.x, Koha simply ignores the very large cardnumber, and falls back to the next longest card. I'm not sure what makes the difference there. Either way, it's not working as desired. Created attachment 107492 [details] [review] Bug 26035: Add tests to highlight the problem I've failed to provide a solution. But I am attaching the tests I wrote in case somebody else wants to give it a try. So if we don't cast the cardnumber as an integer, mysql doesn't know how to properly determine the highest cardnumber. It treats them as as strings and oputs 42 higher than 218250005. If we replace "CAST(cardnumber AS SIGNED" with "(cardnumber + 0)," the math forces mysql to treat it as a number, but we end up with a cardnumber in scientific notation if our existing biggest cardnumber is as big as the initial example (603628999632182575912). I played around with "use bigint" and "use Math::BigInt" but didn't get quite work. They both went from 603628999632182575912 to 603628999630000000001, suggesting that it's still going to scientific notation and then back again poorly. Created attachment 107522 [details] [review] Bug 26035: AutoMemberNum should support cardnumbers up to 32 characters To test: 1- create a patron with cardnumber 12345678901234567890123456789012 (or any 32 character number) 2- turn on AutoMemberNum 3- create a new patron, save without a cardnumber 4- confirm that new patron has a cardnumber one more than the number from step 1 Created attachment 107655 [details] [review] Bug 26035: AutoMemberNum should support cardnumbers up to 32 characters To test: 1- create a patron with cardnumber 12345678901234567890123456789012 (or any 32 character number) 2- turn on AutoMemberNum 3- create a new patron, save without a cardnumber 4- confirm that new patron has a cardnumber one more than the number from step 1 Signed-off-by: Donna Bachowski <donna@bywatersolutions.com> There is a problem noted by the QA script - can you please check? FAIL Koha/Patron.pm FAIL valid Useless use of a constant (1) in void context I also have some issues with the unit tests failing: # Failed test 'No tests run for subtest "fixup_cardnumber"' # at t/db_dependent/Koha/Patrons.t line 2237. Can't call method "cardnumber" on an undefined value at t/db_dependent/Koha/Patrons.t line 2219. # Looks like your test exited with 2 just after 42. t/db_dependent/Koha/Patrons.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 1/42 subtests Test Summary Report ------------------- t/db_dependent/Koha/Patrons.t (Wstat: 512 Tests: 42 Failed: 1) Failed test: 42 Non-zero exit status: 2 Files=1, Tests=42, 29 wallclock secs ( 0.08 usr 0.01 sys + 22.72 cusr 4.31 csys = 27.12 CPU) Result: FAIL I was just checking on the status of this bug. Has anything change on this? |