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).
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.
I discovered that twitter doesn't have 'www' in the url anymore, no '@' symbol and interestingly no trailing slash. I added back the '@' just so we can test that still.
Using a regex group we can cater for optional www in a single regex.
Allowing creation and deleting via the user association.
It probably won't be much effort to allow editing and multiple records, but I cut it down to the minimum needed to avoid any further delays.
I couldn't find a way to test a failure in the destroy method, but decided to keep the condition because I thought it was worth having.
Using the clever concurrency testing borrowed from SubscriptionPlacementJob, but I thought a shorter pause time (just 100ms) would be sufficient.
I considered doing this with a new 'state' field (upcoming/open/close), but decided to keep it simple.
Although we won't be allowing multiple in the this PR, we certainly plan to in the future.
The migration helper add_reference couldn't handle the custom column name, so I had to put it together manually.
This will store the URL for each user that wants a notification.
We probably don't need URL validation (it's not done on Enterprise for example). It could be validated by browser input, and anyway will be validated if the webhook actually works or not.
Inspired by Keygen: https://keygen.sh/blog/how-to-build-a-webhook-system-in-rails-using-sidekiq/
