We introduced a list of formats we support and forgot to add webp. Now I
added that as allowed format again and modified the error message.
I removed the first sentence from the error message because it's very
similar to the default error which is shown as well.
Strips '+' and ' ' characters from the phone number for the generated
link, but doesn't guarantee the link is valid because the number
registered isn't validated for now.
Australian production had one JPG image which was not recognised as
such. The `content_type` was missing and trying to generate a URL for a
variant raised an error and crashed the page.
Testing for `variable?` includes testing for `attached?` and is more
defensive.
We configured Paperclip to convert images to JPG in some cases but I
omitted that here because we don't need it. If an image is better
represented as PNG or another format then the user should be able to
choose that.
Some specs were also testing the generated URL but the Active Storage
URL doesn't contain a style name anymore and it's not helpful to test
the URL.
We do this for all models in the code base. There's one special case,
the ConentConfiguration which is not a model and we can't use the same
approach there. We will have to deal with that separately later.
As a general rule, if you're triggering an email job as part of an after create/save callback, it should use after commit instead.
Why? The transaction can't finish until after the record is persisted (the data is committed) which includes the logic in all callbacks. So for example if the transaction fails after the email job has been placed it will be rolled back, but the email job will already be in the queue, and it'll be referencing a record that doesn't actually exist (due to the rollback).
This for new changes to the enterprise registration/signup flow where a map will be displayed when people are filling in their address. On this map people can check the geocoder has geocoded their address correctly and if not they can manually adjust their latitude/longitude on the map.
But currently every time someone changes their address in the Admin > Enterprise > Address section the address would automatically be geocoded so this could overwrite the latitude/longitude that was set during sign up. To prevent the latitude/longitude from being overwritten this add's a checkbox which people need to explicity click if they want their address to be automatically geocoded, otherwise it will just use the manually configured latitude/longitude.
Note this new feature which allows people to select their location on a map during registration only works with Google maps so far. So if an instance is using Open Street Map this change also adds support for passing a :use_geocoder parameter to the Api::EnterprisesController during registration so that the address will be geocoded on the backend without the use of a map.
