Numeric types in postgres are treated like decimals, except they can
have no length, precision or scale components defined.
IE does not accept 1.00000 as a valid step attribute so we'll default to
any when we encounter decimal types with no length.
Refs #7497
If a visible input is created *after* a hidden input was created, the
form would always blackhole unless the visible input had the same value
as the hidden input.
Refs #7274
FormHelper::input does not respect 'value' option when form is of date/time type.
Signed-off-by: mark_story <mark@mark-story.com>
Backport fixes from #7082 to 2.7
Int casting the decimal scale isn't going to work in a number of
situations as users may end up trying to include decimal points, commas
or spaces in larger amounts.
Fixes#5977
When some but not all inputs were disabled radio buttons were omitted
from the security hash. This caused blackhole failures as the input was
unexpected.
Refs #5603
When the disabled attribute is just array(1), then the attribute should
be filtered out of select element attributes. This is kind of a hacky
workaround but changing the underlying attribute handling is going to be
pretty tricky and far more dangerous.
Fixes#3546
While including the entire protocol, host, port, path and query would be
even better in theory, it gets complicated when proxies and load
balancers are involved.
Fixes#3442
By including the URL in generated hash for secured forms we prevent
a class of abuse where a user uses one secured form to post into a
controller action the form was not originally intended for. These cross
action requests could potentially violate developer's mental model of
how SecurityComponent works and produce unexpected/undesirable outcomes.
Thanks to Kurita Takashi for pointing this issue out, and suggesting
a fix.
If inputs are placed outside of the form elements the form attribute
needs to be set on the hidden inputs. Without this attribute the empty
state does not submit correctly.
Fixes#3053
