-
-
Notifications
You must be signed in to change notification settings - Fork 807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ransack! method which raises error if passed unknown condition #1132
Add ransack! method which raises error if passed unknown condition #1132
Conversation
b0179a4
to
49167be
Compare
@alipman88 thank you for this PR. 🎸 Can I suggest you rebase as there have been a lot of fixes to Ransack, so this might pass the CI now. It is a nice feature, and I'm wondering if as part of this PR the |
49167be
to
150eeb2
Compare
b3c841b
to
7ee824a
Compare
Getting back around to this - thanks for your patience, @seanfcarroll.
Good catch. I've updated the readme to include include both the
I took a glance at the options in The slight exception is the
|
a7861a7
to
48c6d32
Compare
nvm - I have no idea how, but I had commented out the |
It's been eight years since Ransack succeeded MetaSearch. As most developers have likely migrated from MetaSearch to Ransack by now, anyone reading the readme is likely starting fresh with Ransack - so it's perhaps less useful to highlight differences from MetaSearch in the readme's introduction. Move the "Updating From MetaSearch" section to the bottom of the readme, and make sure any important details (like setting the default search param) are covered appropriately within the readme.
48c6d32
to
f085e8a
Compare
This looks pretty useful, what do you think @deivid-rodriguez ? |
I'm sorry @seanfcarroll, I don't have time at the moment to evaluate this. If it looks good to you, please move it forward, otherwise I can give it a look when I find time 👍. |
@alipman88 😄 that will do it! |
Use case: We use Ransack for both public-facing search pages and internal purposes such as targeting bulk email deliveries. In the context of public-facing search, we'd like to be lenient with unknown/invalid search params. However, in the context of targeting bulk emails, this seems dangerous - a broken query could potentially go out to many more recipients than intended.
Thus, we'd like to be able to trigger the
ignore_unknown_conditions
config option on a case-by-case basis. (Previously requested in #535)I've drafted what feels like a clean implementation, although here are some other options I considered:
If folks like this idea but have a different preference for implementing it, let me know and I'll adjust this PR accordingly!