The default queue name used by `deliver_later` is no longer `mailers`.
This commit removes the misleading information from the class
documentation
Ref: #40848
- Action Mailer delivery job should modify their `perform` method
signature in order to receive the new payload that Action Mailer
sends.
Before:
```ruby
def perform(mailer, mail_method, delivery_method, *args)
end
```
After:
```ruby
def perform(mailer, mail_method, delivery_method, args:)
end
```
This new behaviour was introduced couple years ago in a attempt to
get rid of the necessity to have a different job for paramterized
mailers. A deprecation was introduced for custom jobs inheriting
from `ActionMailer::DeliveryJob` but for jobs that didn't it went
unnoticed.
The deprecated behaviour was supposed to be removed in Rails 6.1
but we couldn't and it got reverted https://github.com/rails/rails/pull/39257
Follow up to c07dff72278fb7f2a3c4c71212a0773a2b25c790.
Actually it is not the cop's fault, but we mistakenly use `^`, `$`, and
`\Z` in much places, the cop doesn't correct those conservatively.
I've checked all those usage and replaced all safe ones.
Generators generate things, but what is meant by 'Stubbing out' might
confuse beginners and non-native English speakers.
While generated tests are stubs that should have an implementation, a
generated model is a valid model that doesn't require any changes.
details_cache_key already references Template::Types.symbols and view
resolvers cache based on default_formats and other values. This
previously wasn't an issue because no views had been looked up before
this was set. Now that we are building a regex from the values of
Template::Types.symbols we need to clear cache after changing this
setting.
This reverts commit 0f9249c93f402d276730fcfaba1ed1b876ee7c26.
Reverted because this wasn't warning in custom jobs and therefore
applications may have not seen the deprecation. We'll need to fix the
deprecation to warn for custom jobs so that applications can migrate.
`url_for` will now use "https://" as the default protocol when
`Rails.application.config.force_ssl` is set to true.
Action Mailer already behaves this way, effectively. This commit
extends that behavior application-wide.
Closes#23543.
Followup to 88fe76e69328d38942130e16fb65f4aa1b5d1a6b.
These are new in RuboCop 0.80.0, and enforce a style we already prefer
for performance reasons (see df81f2e5f5df46c9c1db27530bbd301b6e23c4a7).
Add missing bullet point to make clear this is
actually a separate option from
`:openssl_verify_mode`.
Add `:ssl/:tls`-option to guides as well [ci skip]
Without this change, `attachments.inline['my_attachment'].present?`, for example,
would raise the exception `Can't add attachments after mail was called`.
I first brought this issue up at https://github.com/rails/rails/issues/16163#issuecomment-437378347.
Note that this commit addresses only one of the 2 problems I described in that comment.
The other problem is that using `attachments.inline['my_attachment']` for reading an
attachment is unnecessary--it's the same as `attachments['my_attachment']`--even before
`mail` is called. We could add a warning about the unnecessary use of `inline` but I'm
saving that for a later PR since my comment has not received any feedback yet.
Previously this used self.formats= to set the format which render would
use to find templates. This worked, but was untested, and looked a
little confusing because it was doing the mutation within a loop.
This commit replaces the assignment with passing formats: [format] into
the render call, which makes it more obvious that that's the purpose of
the format. It also adds a test to verify the formats being used.
Templates only have one format. Before this commit, templates would be
constructed with a single element array that contained the format. This
commit eliminates the single element array and just implements a
`format` method. This saves one array allocation per template.
Since production applications typically run with log level info and
email adresses should be considered as sensitive data we want to prevent
them from ending up in the logs. In development mode (with log level
debug) they are still logged as part of the Mail::Message object.
