`ostruct` was being implictly required by the `json` gem. But once it
was upgraded, these tests failed to initialize `OpenStruct`.
While we're trying to remove `ostruct` usage in #51510, CI is currently
failing so I'm pushing these in the mean time.
Since #50715, there are cases where `ActiveJob::Arguments` is used
but not required anymore in the test environment. This could be a
test for a custom argument serializer.
One solution could be to add a require "active_job/arguments" in
all the usages, but that isn't a convention we follow in Rails.
Instead, let's register the autoload for `ActiveJob::Arguments` in
`active_job.rb` so that it's always available when needed.
The Rails documentation uses the `:include:` directive to inline the
README of the framework into the main documentation page. As the
README's aren't in the root directory from where SDoc is run we need to
add the framework path to the include:
# :include: activesupport/README.md
This results in a warning when installing the gems as generating the rdoc for the gem is run from the gem/framework root:
Couldn't find file to include 'activesupport/README.rdoc' from lib/active_support.rb
The `:include:` RDoc directive supports includes relative to the current
file as well:
# :include: ../README.md
This makes sure it works for the Rails API docs and the separate gems.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Now that we no longer support Ruby 2.7, many `ruby2_keyword` calls
can be eliminated.
The ones that are left could be eliminated but would end up substantially
slower or more compliacated so I left them for now.
Until now, Rails only droped compatibility with older
rubies on new majors, but I propose to change this policy
because it causes us to either keep compatibility with long
EOLed rubies or to bump the Rails major more often, and to
drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd
be much better to just drop support in new minors whenever they
go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even
a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we
can already drop Ruby 3.0 as it will be EOL in March.
It's possible since Rails 6 (3ea2857943) to let the framework create Event objects, but the guides and docs weren't updated to lead with this example.
Manually instantiating an Event doesn't record CPU time and allocations, I've seen it more than once that people copy-pasting the example code get confused about these stats returning 0. The tests here show that - just like the apps I've worked on - the old pattern keeps getting copy-pasted.
In case of mail delivery errors, the old ActionMailer::LogSubscriber
erroneously logged a "Delivered mail ..." line.
With this change it checks the passed exception object and logs a
"Failed delivery of mail" line instead.
Co-authored-by: Christian Esser <c_esser@yahoo.de>
Fixes https://github.com/rails/rails/issues/48477
Using forms inside emails is not common, but it's possible, and it's also possible to share views between controllers and mailers. Currently if a controller sets a `default_form_builder` that's different from the global config, mailers that use the same views will not default to the same `FormBuilder`. To fix this, this PR adds a `default_form_builder` method for mailers that does the same thing as its controller sibling.
There are assertions that expected/actual arguments are passed in the
reversed order by mistake. Enabling the LiteralAsActualArgument rule
prevents this mistake from happening.
The existing tests were auto-corrected by rubocop with a bit of
indentation adjustment.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Since 6983a89c72 `require_dependency` is
obsolete since Rails stopped supporting classic mode.
It is only used by engines that need to support classic mode as well.
We can safely remove internal usage of `require_dependency`.
It was only used in the ActionMailer::Preview which is using just
`require` anyway.
Since this method has been documented in the guides for ages, it's probably safe.
https://guides.rubyonrails.org/testing.html#revenge-of-the-fixtures
TODO: I don't like how these methods are documented on
ActionMailer::TestCase::Behavior, even though the API is meant to be
exposed through ActionMailer::TestCase
Also add some additional words to make it clear that the modules also
implement handling the exceptions configured with rescue_from, because
it was not immediately clear that happened without reading the code.
In #45752, a `:params` kwarg was added to `assert_enqueued_email_with`
so that mailer params and args could be specified simultaneously.
However, for backward compatibility, the old behavior of treating an
`:args` Hash as params was preserved. The result is that if both
`:params` and `:args` are specified and `:args` is a Hash, `:params` is
ignored.
This commit deprecates specifying params via `:args` (i.e. passing a
Hash to `:args`).
After the deprecated behavior is removed, it will be possible to pass
a Hash to `:args`, and the Hash will be treated as named args instead.
Support args/params proc matchers in `assert_enqueued_email_with` to
make it behave more like `assert_enqueued_with`.
Fix#46621.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
The `Type` class was introduced in https://github.com/rails/rails/pull/23085
for the sole purpose of breaking the dependency of Action View on Action Dispatch.
Unless you are somehow running Action View standalone, this is actually
never used.
So instead of delegating, we can use constant swapping, this saves us
a useless layer.
Ultimately we could consider moving `Mime::Types` into Active Support
but it requires some more thoughts.
Currently when opening the main framework pages there is no introduction
to the framework. Instead we only see a whole lot of modules and the
`gem_version` and `version` methods.
By including the READMEs using the `:include:` directive each frameworks
has a nice introduction.
For markdown READMEs we need to add the :markup: directive.
[ci-skip]
Co-authored-by: zzak <zzakscott@gmail.com>