Check type before sending #value message to predicate#1468
Check type before sending #value message to predicate#1468scarroll32 merged 3 commits intoactiverecord-hackery:mainfrom
#value message to predicate#1468Conversation
Issue: activerecord-hackery/ransack#1467 PR: activerecord-hackery/ransack#1468 Hopefully the PR will be merged soon so we can remove this patch.
|
Interestingly, CI is not running on the PR 🤷 |
Issue: activerecord-hackery/ransack#1467 PR: activerecord-hackery/ransack#1468 Hopefully the PR will be merged soon so we can remove this patch.
Issue: activerecord-hackery/ransack#1467 PR: activerecord-hackery/ransack#1468 Hopefully the PR will be merged soon so we can remove this patch.
Needs to be approved for the 1st run. |
|
@spaghetticode could you please add a test for this change? |
The previous implementation was giving for granted that every predicate respond to `#value`, but that doesn't seem to be the case at least when having a `Arel::SelectManager`. by simply inverting the terms of the existing AND check we can fix the issue without introducing unknown side effects. In order to test the change, a new ransacker has been added to the Person model.
e72e954 to
e7c8250
Compare
|
@scarroll32 I've just added a test that fails without the change. The method I modified is private, so it needs to be tested indirectly. I followed the existing examples, but I had to add a new ransacker to the |
Solidus core's gemspec already required that ransack be '~> 4.0', but the latest version of ransack, v4.2.0, released July 10 2024, introduces a bug. The previous implementation was taking for granted that every predicate would respond to #value, which doesn't seem to be the case when the predicate is an instance of a Arel::SelectManager. This has already been flagged by @spaghetticode in his PR against ransack: activerecord-hackery/ransack#1468 Since there has been little movement on this PR since January, we should lock to a version that works for us since currently many of our product specs are failing. (eg. spec/models/spree/product_spec.rb:659) We can remove this lock once the PR is merged and once the above test (and the others that are failing) are able to pass in ransack v4.2.0 or subsequent versions.
|
I am also having this issue, will there be any movement on this PR @scarroll32 ? For now I have locked my gemfile to |
Solidus core's gemspec already required that ransack be '~> 4.0', but the latest version of ransack, v4.2.0, released July 10 2024, introduces a bug. The previous implementation was taking for granted that every predicate would respond to #value, which doesn't seem to be the case when the predicate is an instance of a Arel::SelectManager. This has already been flagged by @spaghetticode in his PR against ransack: activerecord-hackery/ransack#1468 Since there has been little movement on this PR since January, we should lock to a version that works for us since currently many of our product specs are failing. (eg. spec/models/spree/product_spec.rb:659) We can remove this lock once the PR is merged and once the above test (and the others that are failing) are able to pass in ransack v4.2.0 or subsequent versions.
Solidus core's gemspec already required that ransack be '~> 4.0', but the latest version of ransack, v4.2.0, released July 10 2024, introduces a bug. The previous implementation was taking for granted that every predicate would respond to #value, which doesn't seem to be the case when the predicate is an instance of a Arel::SelectManager. This has already been flagged by @spaghetticode in his PR against ransack: activerecord-hackery/ransack#1468 Since there has been little movement on this PR since January, we should lock to a version that works for us since currently many of our product specs are failing. (eg. spec/models/spree/product_spec.rb:659) We can remove this lock once the PR is merged and once the above test (and the others that are failing) are able to pass in ransack v4.2.0 or subsequent versions. (cherry picked from commit 1664d10) # Conflicts: # core/solidus_core.gemspec
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a bug where Ransack was incorrectly assuming all predicates respond to the #value method, which causes issues with certain Arel objects like Arel::SelectManager. The fix reorders the type checking in the casted_array? method to ensure type safety before method calls.
- Reorders boolean logic in
casted_array?method to check type before calling#value - Adds a new ransacker for
article_tagsthat usesArel::SelectManager - Adds test coverage for HABTM associations using the new ransacker
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| lib/ransack/nodes/condition.rb | Fixes the type checking order in casted_array? method |
| spec/support/schema.rb | Adds new article_tags ransacker that returns Arel::SelectManager |
| spec/ransack/adapters/active_record/base_spec.rb | Adds test case for HABTM associations functionality |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Closes #1467
The previous implementation was giving for granted that every predicate respond to
#value, which doesn't seem to be the case at least when having aArel::SelectManager.by simply inverting the terms of the existing AND check we can fix the issue without introducing unknown side effects.