https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43193 Bug ID: 43193 Summary: Non-numeric offset or creep values on printer profiles cause a 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger@veritassuperaitsolutions.com Reporter: chris.nighswonger@veritassuperaitsolutions.com QA Contact: testopia@bugs.koha-community.org Target Milestone: --- The offset and creep fields on both printer profile editors are plain text inputs whose values are passed straight to the database: labels/label-edit-profile.pl patroncards/edit-profile.pl printers_profile.offset_horz, offset_vert, creep_horz and creep_vert are float NOT NULL. Typing ordinary non-numeric text into any of the four fields -- "abc", or the European decimal form "1,5" -- sends that string to the column. On an installation running STRICT_TRANS_TABLES the insert or update raises a database exception, which surfaces to the user as a bare 500 error page. Without strict modes the value is silently coerced to 0 with a warning, so the profile saves with an offset the librarian did not ask for. No tampering is needed; the inputs are type="text" and accept anything typed into them. To reproduce (strict SQL modes enabled): 1. Cataloging > Label creator > Manage > Printer profiles > New profile (or Tools > Patron card creator > Manage > Printer profiles > New profile) 2. Enter a printer name and paper bin. 3. Type "abc" into the horizontal offset. 4. Save. -- a 500 error page is returned rather than a validation message Bug 21052 made the related empty-string case safe: a cleared offset now coerces to 0 in both editors, and that patch also added handling so a duplicate profile no longer 500s. Non-empty non-numeric input was left out of scope there because it is a different defect class -- it wants server-side numeric validation (and probably type="number" or inputmode on the four inputs, in both editors), rather than a default for a missing value. Found during multi-model review of the bug 21052 patch. -- You are receiving this mail because: You are watching all bug changes.