https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Nice spot, Philip. This is a tricky one. I hoped that maybe checking the size of the array created by ($from .. $to) would be enough, but it turns out that ($from .. $to) is a very heavy CPU and RAM intensive operation itself when using the values 100101224 and 1000101274. On the face of it, we could minus $to from $from to get a difference to try to validate, but... I think barcodes are not necessarily positive integers. The ".." Perl range operator also has a magical auto-increment algorithm when applied to strings, so it might be difficult to take into account that magic... That being said... if you put $from = 'ax' and increment is with $from++, you'll get 'ay' same as when using the ".." range operator. So using a for loop with ++ increment operator and a max count might work. That should have a number of advantages in terms of CPU and RAM usage actually since the calculation should be quite stable. We'd also want another variable to test the last generated value, because something like: "from *x to az" will only yield *x, so you wouldn't want to increment 10000 times and get *x for each iteration. Anyway... perhaps not a perfect solution but hopefully it would be practical? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com --- Comment #3 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- *** Bug 42601 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 --- Comment #4 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 199142 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199142&action=edit Bug 41162: Don't allow strings of different length We already have a validator function to prevent this, however, it just returns 'true' in most cases when I believe it is meant to return the variable 'result' This won't prevent the letter cases highlighted in the comments, but as library barcodes are generally a fixed length it seems reasonable to at least restore this intention Note: In the cases where the inputs start with '0' we do some handling, but it seems only to be clearing previous errors? To test: 1 - Browse to Cataloging->Label Creator->Print barcode range 2 - Enter From: 1 To: 10 3 - Form is submitted 4 - Apply patch 5 - Reload the 'Print barcode range' page: http://localhost:8081/cgi-bin/koha/labels/label-edit-range.pl 6 - Enter From: 1 To: 10 7 - You are prevented from submitting 8 - Try any different length values - you are prevented -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199142|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 Laura O'Neil <laura@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rschumann@utah.gov -- You are receiving this mail because: You are watching all bug changes.