I changed the text to focus on the resolution: the user needs to choose
a tax category or a different calculator.
I associated the error to the model to prevent the attribute name from
being included in the error message. Alternatively, we could have
changed the name of the attribute to match the UI. But this error
affects the combination of two attributes, none of them is invalid on
its own.
I'm using Rails' default lazy lookup for error messages which results in
shorter code and a standard structure.
I also added a simple spec.
We're now handling these values on the frontend, so can keep this simple.
fixes up:
Add numericality validation for *
Add translation for Active Record error message
The browser is now responsible for dealing with the decimal separator, for all numeric preferences (as input[type=number]; see Spree::Admin::BaseHelper::preference_field_tag). Calculators are the only place that numeric preferences are used.
It will enforce that only one comma or dot (depending on user's locale) is entered, thus avoiding any ambiguity, and mis-interpretation (eg 100,001 could be interpreted as more than 100 thousand or 100 with a decimal place).
This option came from Spree and we never used it. The config input field
is disabled in the admin interface and I checked our managed databases.
I don't think that we will want this feature in the future either.
Staging sends unmodified emails which is more realistic and we haven't
had a use case to intercept those emails. There's still the BCC option
if we need additional access.
They're all numbers, so we can reliably validate in the browser, removing the need for additional validation logic.
They will still be validated server-side, and in the unlikely even that there is an error, the generic 'Calculator is invalid' message will appear, with the relevant fields highlighted red. I think that's fine.
But we still have the duplicate problem.
Wait a minute, it copies them in the same format that I am copying them. So.. I don't need to copy them at all!
Now I see that we just needed the right format in the translation file.
This is much simpler. Multiple messages get combined onto one line though, which is not perfect.
And.. it still seems to duplicate the errors. Weird, it's fine on my frontend though.
