Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

<cfqueryparam null=true> not ignoring sqltype

Description

Upgraded to 5.3.3.62 yesterday (default null behaviour) and started getting errors on a standard type of <cfqueryparam value="#form.max_age#" null="#isEmpty(form.max_age)#" sqltype="tinyint" maxlength="2"> edit query which has never caused issues before. My understanding is that null=true should essentially cause it to read as <cfqueryparam null=true> and ignore value (and sqltype), but it seems that behaviour has changed and the sqltype is actually being checked? I have searched the open issues but can't find any mention of this. Am I misunderstanding something? I have removed sqltype="tinyint" to 'fix' the issue, but don't really like removing that. I can of course rewrite this to have a different cfqueryparam in case of empty values, but thought this was the entire point of null=true.

Environment

None

Activity

Show:

Sam Daams 3 June 2020 at 10:17

Sorry, I haven’t had a chance to check this yet due to Covid disruptions, but doing some dev work from Friday on and will revert then.

Michael Offner 29 May 2020 at 15:48

?

Pothys - MitrahSoft 4 May 2020 at 08:39

,
I hope, for the issue what are you mentioned above, it was fixed in 5.3.5.47-SNAPSHOT onwards. So, could you please check and report here back.

Michael Offner 1 May 2020 at 14:46

can you please answer that question

Sam Daams 5 December 2019 at 08:47

While great this particular issue tied to maxlength is fixed, does this also fix the much bigger bug where when inputting any kind of financial data (decimal) the maxlength field is wrong due to how it’s converting the number prior to counting the characters? I’ve had to change existing code in about 100 places (basically removing maxlength, which should be a useful tool and I thought recommend use for all?) to still allow users to input important financial data because maxlength is totally broken and counting spaces and commas where they don’t exist. These are just my use cases, but I’d imagine all these bugs (and potentially others around maxlength) are tied to the ‘fix’ for this ticket: https://luceeserver.atlassian.net/browse/LDEV-2260 Which interestingly enough the reporting user also mentions is “probably not the desirable way to convert values”. I’m all for making things match ACF, but it should not happen at the expense of security (ACF handles the maxlength and decimal just fine, so as it is now, making the prior case compatible broke a much more important compatibility imo).

Fixed

Details

Assignee

Reporter

Priority

Labels

Fix versions

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Created 20 November 2019 at 11:07
Updated 29 August 2022 at 13:59
Resolved 29 August 2022 at 13:59

Flag notifications