I have a special case here: I want to match survey IDs to IDs of another application.
I'd need a few more digits in the survey ID.
The DB has int(11) for surveyID, so I took a bold step, edited the maxlength="6" property in the input when cloning a survey, set it to 10, entered a longer surveyID and everything seems to work out flawlessly.
Is this safe? Will I run into problems further on?
Why is the input restricted to 6 digits when the backend seems to be designed for more?
If it is just this single location of code that restricts the input to 6 digits - may I ask to increase it to the limit the backend is capable of, so others can benefit as well? There's no real downside to this - people can choose shorter IDs any time.
Thanks in advance!
PS: I am also open to suggestions for an added exportable field that could be shown on queXF PDF printouts (I tried making an input field readonly with JS and setting a default value, which works perfectly for the online view, but the exported PDF prints the JS instead of interpreting in. I would not be able to scan & interpret the numbers anyway, as ICR does not quite work out with queXF (at least Adam Zammit of queXF more or less told me not to use ICR because it does not really work that well). I'd just need to show the ID on the PDF and also have it exportable. Like a global property of a survey like the fax number, but in such a way that it can also be shown in the PDF.
For now, using longer surveyIDs should be OK and I think I should not mix these two possible solutions into one topic here. However - if anyone sees an easy solution, just say so and I'll open up another topic!
Regarding the downsides:
True - but only if you choose to user longer IDs. It's not mandatory to use 10 digits. Just as much as it isn't mandatory to use 6 digits right now. You can even get away with 1 digit (a few times, that is )