take non-ransack key out of ransack hash key (was: Ransack should work identically in production and dev.)

[eddierubeiz]

In config/initializers/ransack.rb the line c.ignore_unknown_conditions = Rails.env.production? has caused confusion several times. The setting also prevents developers from testing the filter for review_requested and ocr_requested.

c.ignore_unknown_conditions should probably not have different settings in dev and production.

[eddierubeiz]

We've also discussed getting rid of ransack completely, which could be another ticket.

[jrochkind]

So I think the initial thinking (of me or of ransack defaults) was that in production you don't want an error for this, you just want a no-op -- but in development, you want to know you've asked for something ransack will do nothing with.

if they are going to be the same in both... I'd almost want it to be false in both, to raise in both!

But then we'd still have this problem.

The issue, I think, is we're putting a param in the ransack sub-hash, that ransack isn't actually handling.

So other solutions might be:

• Change the key of this param to NOT be in ransack sub-hash, so ransack doesn't even know about it -- we're already, I think, not actually using ransack for these attributes, but we're putting them in the hash we give to ransack anyway, previously counting on ransack to ignore them
• Leave them where they are, but after our code adds a SQL condition by processing them, delete them from the params hash, so they don't remain for ransack to complain about

The first one is probably best? If I understand what's up right and it works?

[eddierubeiz]

Yeah - I'm in favor of option 1.