[Feature] Setting to make auto filter apply default to off

[t3hmrman]

Need for this feature
Putting in filter options can be a bit annoying due to the password popup appearing when an invalid filter is immediately applied, before it's been completely specified.

Is your feature request related to a problem? Please describe.
At present there's a bug (?) where certain inputs of filter options generate errors when executed immediately (autoApplyFilter) and the password prompt is displayed (I assume this is because of some error handling which assumes the error that came back was an access error? The sheet in question is not password protected).

Describe the solution you'd like
A way to specify the default for whether filters are auto applied. I'd like to make the default of NocoDB be to not apply filters immediately.

Describe alternatives you've considered

Additional context

Related code paths:

• Frontend code governing checkbox via the autosave reactive variable
• Default state that seems to governautoApplyFilter

[o1lab]

Thank you for pointers. Is this for a shared view ? or just a regular view.

[o1lab]

We'd fixed a problem similar since you'd mentioned it in a reddit thread :)

If you can provide an example where filter options generate errors ? it would be helpful.

Also pls provide the version details of nocodb (right top menu)

[t3hmrman]

Thank you for pointers. Is this for a shared view ? or just a regular view.

This was a shared view (those trying to view it are not logged in), but I want to note that I only have one view on the table I am sharing and that's the view that is being shared.

In trying to reproduce it I've noticed that I can break the shared view by simply inputting an incomplete filter (partially filled out) -- I must remove the incomplete where clause otherwise when trying to view the data (in another private window), the password popup appears (signifying an error, if I'm guessing right).

What's happening does make sense, looks like incomplete filters are auto-applied ("filter completion" is hard to guess) and applying is modifying and persisting the changed view in real time (saving the updated query) which is what is causing the failure.

We'd fixed a problem similar since you'd mentioned it in a reddit thread :)

Greatly appreciate it, I'm getting a ton of mileage out of NocoDB on a salary sharing site I launched (that's the project I'm having the issue on), so I can only give my thanks!

If you can provide an example where filter options generate errors ? it would be helpful.
Also pls provide the version details of nocodb (right top menu)

Will do! I'm going to take a closer look, maybe do some recordings and update this issue. My version data is here, apologies should have included it right away:

Node: **v12.22.6**
Arch: **x64**
Platform: **linux**
Docker: **false**
Database: **pg**
ProjectOnRootDB: **false**
RootDB: **sqlite3**
PackageVersion: **0.83.8**

[EDIT] Please find some screen captures from reproduction below:

Step 1: Enter an invalid filter (ex. trying to filter a numeric column with LIKE:

set-invalid-filter.mp4

Step 2: Attempt to load the sharable URL for the view (I simply reload the page, since I was already on it before the invalid filter was entered):

reload-shared-view.mp4

As you might expect there's a 400 error from NocoDB itself:

{
  "msg": "select \"salaries\".\"id\" as \"Id\", \"salaries\".\"job_title\" as \"job_title\", \"salaries\".\"salary_usd\" as \"salary_usd\", \"salaries\".\"country\" as \"country\", \"salaries\".\"state_or_province\" as \"state_or_province\", \"salaries\".\"town\" as \"town\", \"salaries\".\"source_url\" as \"source_url\", \"salaries\".\"area_col\" as \"area_col\", \"salaries\".\"has_cpa\" as \"has_cpa\", \"salaries\".\"field\" as \"field\", \"salaries\".\"accounting_area\" as \"accounting_area\", \"salaries\".\"is_big4\" as \"is_big4\", \"salaries\".\"years_experience\" as \"years_experience\", \"salaries\".\"bonus_annual_usd\" as \"bonus_annual_usd\", \"salaries\".\"hours_per_week_avg\" as \"hours_per_week_avg\", \"salaries\".\"busy_szn_hours_per_wek_avg\" as \"busy_szn_hours_per_wek_avg\", \"salaries\".\"inserted_at\" as \"inserted_at\" from \"salaries\" where \"salaries\".\"years_experience\" like $1 order by \"inserted_at\" desc limit $2 - operator does not exist: integer ~~ unknown"
}

In a slightly easier to read format:

select salaries.id as Id, salaries.job_title as job_title, salaries.salary_usd as salary_usd, salaries.country as country, salaries.state_or_province as state_or_province, salaries.town as town, salaries.source_url as source_url, salaries.area_col as area_col, salaries.has_cpa as has_cpa, salaries.field as field, salaries.accounting_area as accounting_area, salaries.is_big4 as is_big4, salaries.years_experience as years_experience, salaries.bonus_annual_usd as bonus_annual_usd, salaries.hours_per_week_avg as hours_per_week_avg, salaries.busy_szn_hours_per_wek_avg as busy_szn_hours_per_wek_avg, salaries.inserted_at as inserted_at from salaries where salaries.years_experience like $1 order by inserted_at desc limit $2 - operator does not exist: integer ~~ unknown

Pretty reasonable output, considering the view query is malformed to begin with -- I'd love to be able to prevent a small change from breaking the external view up front, if possible (attempting to query the data before allowing a filter to be saved might make sense?), but I'd settle for just being able to default the filters to not apply by default so that I don't make the mistake locally.

There are at least a couple things I think could be changed here/might be worth looking into in the future (time permitting, easiest to hardest):

• Allow for setting default auto-apply (this way I can at least
• Force a test of updated view queries before they are allowed to be saved as filters

[o1lab]

This is so helpful & detailed. We will sort this in upcoming release! Thank you so much.

[t3hmrman]

No worries and no rush — the work around is easy and it’s arguably not even a bug! As always thanks for the great software, NocoDB is awesome.

…

On Fri, Jan 21, 2022 at 05:18, Navi ***@***.***> wrote: This is so helpful & detailed. We will sort this in upcoming release! Thank you so much. — Reply to this email directly, [view it on GitHub](#963 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAIJCNRRZF274VCGBYPUR7LUXBUYJANCNFSM5MIRBQXQ). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub). You are receiving this because you authored the thread.Message ID: ***@***.***>

[pranavxc]

@t3hmrman: Look like you are using an older version of NocoDB(0.83.8) kindly please upgrade it to 0.84.6 since we had fixed it in the recent version. If the problem still persists even after the upgrade, feel free to update here.

[t3hmrman]

Hey @pranavxc thanks for the pointer -- I see you're referring to #937 right? That certainly fixes the problem with the password prompt showing up -- I've upgraded and I don't see that issue any more.

I noticed that when people put in invalid filters as well it basically ignores them, so that's also much improved.

I do still want to be able to set the default for auto apply to off, but that's not a huge deal at all anymore when the UI is this much better -- most people will be able to figure out that ineffectual filters just return the whole dataset.

Thanks so much!