Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

EdwinKruglov
Copy link
Contributor

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.

@EdwinKruglov EdwinKruglov marked this pull request as ready for review September 9, 2024 15:57
@EdwinKruglov EdwinKruglov requested a review from a team as a code owner September 9, 2024 15:57
Copy link
Contributor

@hiboabd hiboabd left a 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..

Copy link
Contributor

@mseedat-moj mseedat-moj left a 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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants