-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LAA-APPLY-FOR-CRIMINAL-LEGAL-AID-3X] fix validation issues #1163
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this is something we need to push back on if it’s causing bloating and duplication? Not sure if there have been conversations already though..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good - some questions/suggestions
end | ||
errors | ||
end | ||
# rubocop:enable Metrics/MethodLength |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this method can be simplified to something like:
value = begin
Kernel.Float(send(attribute))
rescue ArgumentError, TypeError
nil
end
return [:not_a_number] if value.nil?
options.map do { |option, arg| validate_numericality_option(option, arg, value) }.compact
Haven't tried it though.
case option | ||
when :greater_than | ||
:greater_than if value <= arg | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how this is working - is the idea that it's just a method confirming the greater_than
error really is a greater_than
error?
@@ -50,6 +50,6 @@ def error_message(obj, error) | |||
"#{obj.model_name.i18n_key}.summary.#{error.attribute}.#{error.type}", | |||
scope: [:activemodel, :errors, :models], | |||
payment_type: payment_type | |||
) | |||
).capitalize |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does capitalize
uppercase every first character in each word?
Description of change
Ensure that numericality validation messages on the Income Payment form have all the necessary information to construct an error message.
Link to relevant ticket
LAA-APPLY-FOR-CRIMINAL-LEGAL-AID-3X
Notes for reviewer
I've implemented a custom numericality validation method in order to have more control over the error messaging, i.e. to be able to provide the
payment_type
value to the error strings. The need for this comes from content changes that require more dynamic field-level error messaging - e.g. "Maintenance payments amount must be greater than 0" instead of "Amount must be greater than 0". Previously, these "fuller" error messages were only shown in the error summary box.Initially I wanted to extend the default
NumericalityValidator
which does all the validation we could want, but I couldn't find a good way to extend it just so I could alter the error messaging.What's also becoming clear is that we end up constructing error messages both at the attribute level and at the summary level when in most (all?) cases the summary error messages will be the same, just repeated above the form. Unless there are cases where summary errors need to differ from field-level errors, this seems like duplicated effort.