Rails main / 7.1.0.alpha introduced a change to improve typography by
default, by converting all apostrophes to be single quotation marks.
https://github.com/rails/rails/pull/45463
The change caused all our text based matching to fail, this updates the
tests to ensure compatibility.
Model tests were changed to test against the error type & information
rather than the translated string, which I think is an improvement
overall that should make them a little less brittle. I thought of using
[of_kind?] but that isn't available on all Rails versions we currently
support, while `added?` is. The drawback is that `added?` require full
details like the `:confirmation` example which requires the related
attribute that is being confirmed, but that's a small price to pay.
Integration tests were changed to match on a regexp that accepts both
quotes. I could've used a simple `.` to match anything there, but
thought I'd just keep it specific for clarity on what it is really
expected to match there. Plus, since it's integration testing against a
rendered response body, it's better to match the actual text rather than
resort on other ways. (like using I18n directly, etc.)
[of_kind?] https://api.rubyonrails.org/classes/ActiveModel/Errors.html#method-i-of_kind-3F
We can't just "swap" those model properties, as that sets instance vars
on the classes that get reverted to their "previous" value, which ends
up leaving the instance vars set as `nil`. However, our logic for those
model/class properties actually checks for `defined?` as a way to
override them, and delegates up to `Devise` global config if they are
not defined, so leaving instance vars back with `nil` values isn't
enough, we need to actually remove them.
This introduces a new test helper specifically for overriding those
model configs so that we can do proper cleanup.
This is an attempt to address the Webrat / Nokogiri compatibility issue
[discussed here]. It monkeypatches Webrat to explicitly add the old
default arguments to the invocation of to_xpath.
Move monkey patch to its own file under test/support/webrat.
I really need to get rid of webrat.
Closes#5475
[discussed here] https://github.com/sparklemotion/nokogiri/issues/2469
Expand tests to check for the actual validatable exception message
This was raising a `FrozenError` on Ruby < 3 where interpolated strings
were considered frozen. This [changed in Ruby 3], since such strings are
dynamic there's no point in freezing them by default.
The test wasn't catching this because `FrozenError` actually inherits
from `RuntimeError`:
>> FrozenError.ancestors
=> [FrozenError, RuntimeError, StandardError, Exception, Object ...]
So the exception check passed. Now we're also checking for the error
message to ensure it raised the exception we really expected there.
Closes#5465
[changed in Ruby 3] https://bugs.ruby-lang.org/issues/17104
Co-authored-by: Martin <martin@edv-beratung-meier.de>
It is indeed recommended for consistency, but Rails will be able to find
the views under `devise/` due to inheritance still, so make that a bit
clearer in the readme docs about customizing controllers, explaining
that copying or moving the views is an optional step.
Closes#5526
[ci skip]
Albeit it's not super recommended, it's possible and even mentioned in
the changelog/wiki in case the app has some additional responder logic
that needs to be applied to Devise across the board.
Explain a bit more about how `data-confirm` and `data-method` need to be
updated to the turbo versions `data-turbo-confirm` and
`data-turbo-method`, respectively. (and depending on its usage.)
[ci skip]
There's some additional information in the wiki upgrade guide for those
interested, but most of it is covered in the changelog and should
suffice.
The post install message should help guide people upgrading to make sure
they know what to do in this new version, since some may be using Turbo
out there with custom responders and failure apps and those would have
to be removed in order to use these new changes fully. Hopefully that's
enough of a nudge for them.
Just want to have something different than the currently released
version to test out more easily. Plus, this is probably going to become
v4.9.0 final soon anyway.
Unfortunately we can't enforce the version in the gemspec because
responders only supports Rails 5.2 now, and Devise still supports
previous versions.
We'll drop support for those in a future major release, so for now I'm
not adding any version.
This also adds a warning in case someone is using an older version of
responders and tries to set the error/redirect statuses via Devise, so
that they know what to do (upgrade responders) in that case.
This changes the OmniAuth "sign in" links to use buttons, which can be
wrapped in an actual HTML form with a method POST, making them work
better with and without Turbo in the app. It doesn't require rails/ujs
anymore in case of a non-Turbo app, as it previously did with links +
method=POST.
Turbo is disabled for those OmniAuth buttons, as they simply don't work
trying to follow the redirect to the OmniAuth provider via fetch,
causing CORS issues/errors.
Rails master on Ruby 2.7/3.0 is failing with the following error:
Resolving dependencies...
Could not find compatible versions
Because every version of rails depends on RubyGems >= 3.3.13
and Gemfile-rails-main depends on rails >= 0,
RubyGems >= 3.3.13 is required.
So, because current RubyGems version is = 3.1.6,
version solving has failed.
Trying to run with the latest available rubygems to see if that can fix
the problem, but sticking to the "default" rubygems version on older
Ruby versions to avoid build issues there.
It appears we're getting a newer version of this multipart-post
dependency, which doesn't work well with Ruby 2.2 by using
`Object.deprecate_constant`, resulting in the following error:
.../multipart-post-2.2.0/lib/multipart/post/parts.rb:152:in `<top (required)>':
undefined method `deprecate_constant' for Object:Class (NoMethodError)
Hopefully by locking on a previous version we can just get the build
back to green for now.
This simplifies the logic considerably, as we don't need to reach out to
what seems more internal-ish implementation of Rails with the
interaction between the request and controller objects.
b925880914
Rails implemented a CSRF token storage strategy to allow storing the
CSRF tokens outside of the sessios (for example, in an encrypted
cookie), and changed how the value is kept around during the request
cycle, by using a request.env value.
We still want to ensure the final session value is cleaned correctly in
the test, but the implementation needed to change since we can't simply
delete from the session anymore, we need to make sure we call the Rails
methods for resetting the current storage strategy so it works with all
of them.
https://github.com/rails/rails/pull/44283
* Rails and Ruby versions follow the most recent to oldest, except for
Rails main, so we can keep the Gemfile the first one.
* Excluding specific matrix combinations based on the Gemfile first,
Ruby version next, and keep the same order (most recent -> oldest)
* Quote all Ruby versions to keep things consistent. It's required for
the '3.0' version to avoid the float issue where it'd use the latest
3.x instead.
