Sdoc 2.4.0 supports a CSS badge that can be set by passing the version
as the HORO_BADGE_VERSION env variable.
The old badge image can be removed, as it no longer needs to be copied
by the docs server: https://github.com/rails/rails-docs-server/pull/28
This commit addresses the following error.
```
% ruby -v
ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [arm64-darwin21]
% cd guides/bug_report_templates
% ruby action_controller_gem.rb
Fetching gem metadata from https://rubygems.org/...........
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
... snip ...
Fetching strscan 3.0.2
Installing strscan 3.0.2 with native extensions
Traceback (most recent call last):
9: from action_controller_gem.rb:5:in `<main>'
8: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/inline.rb:54:in `gemfile'
7: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/settings.rb:124:in `temporary'
6: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/inline.rb:70:in `block in gemfile'
5: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/runtime.rb:26:in `setup'
4: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/runtime.rb:26:in `map'
3: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/spec_set.rb:147:in `each'
2: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/spec_set.rb:147:in `each'
1: from /Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/runtime.rb:31:in `block in setup'
/Users/yahonda/.rbenv/versions/2.7.6/lib/ruby/2.7.0/bundler/runtime.rb:312:in `check_for_activated_spec!': You have already activated strscan 3.0.1, but your Gemfile requires strscan 3.0.2. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
%
```
Background:
- It has been failing since this build
https://buildkite.com/rails/rails/builds/86305#9be4d24a-2944-4660-b5f0-03aac7992131
- strscan 3.0.2 has been released on May 9, 2022
https://rubygems.org/gems/strscan/versions/3.0.2
In our use case - we have a base model that has a default scope that we
want enabled for all queries, ex:
```ruby
class Developer < ApplicationRecord
default_scope -> { where(firm_id: Current.firm_id) }, all_queries:
true
end
```
We're also leveraging a module that will add a default scope to only
find soft-deleted records.
```ruby
module SoftDeletable
extend ActiveSupport::Concern
included do
default_scope { where(deleted_at: nil) }
end
```
Through this, we've found that when using default scopes in combination,
*specifically in the use case where the _non_ all queries scope is
declared first*, that we would get an error when calling `.update`:
```ruby
class Developer < ApplicationRecord
include SoftDeletable
default_scope -> { where(firm_id: Current.firm_id) }, all_queries:
true
```
```ruby
Current.firm_id = 5
developer = Developer.new(name: "Steve")
developer.update(name: "Stephen")
NoMethodError: undefined method `where' for nil:NilClass
```
In digging into the code, this was due to there not being an `else` case
for the `inject` used to combine `default_scopes` together (`inject`
uses the return value of the block as the memoizer).
Without the `else` case, if the block returned `nil`, `nil` was passed
to the evaluation of the next `default_scope`.
This commit adds the `else`, and also makes a minor adjustment in
variable naming (`default_scope` to `combined_scope`) in an effort to
add a little more readability, as we're iterating over an array of
default scopes, but what we're building is _the_ default scope to be
used in the query, etc.
Co-authored-by: Will Cosgrove <will@cosgrove.email>
Before, it was failing to read these columns because their contents
were not encrypted, unless you enabled `config.active_record.encryption.support_unencrypted_data`.
Now, it will detect the change at creation time for these records and
effectively encrypt those values, preventing the problem.
Fixes#44314#43664Closes#44993
Co-authored-by: Dima Fatko <fatkodima123@gmail.com>
Performing strict_loading! on a model with a polymorphic association
currently raises an ArgumentError because it attempts to look up the
klass on the polymorphic association, which is not possible. The error
message for StrictLoadingViolationError on models with polymorphic
relationships should omit the klass for the association.
Vue.js, alpinejs, and potentially other JS libraries support tags
starting with `@` symbols. This was broken by the recent security release in
649516ce0f
I've only added `@` to the list even though there are potentially other
safe characters. We can add more if necessary (and if safe).
Fixes:
* #45014
* #44972
Jean Boussier