0️⃣

SkrOYC · 01-30-2023 08:38 AM

I'm just so tired that I don't have time to explain all details.

I started receiving this for multiple apps/users

After checking, it doesn't have any circular reference so it shouldn't complain. Also it worked perfectly until a couple of days

@lizlynch @dbaum @Michelle

lizlynch

@SkrOYC - Will raise this issue to the AppSheet dev team.

ahmedTaj

I have similar issue,

1minManager

Related to:

Rollout changes

*Item*	*Description*
Enhancement	An alert message is now issued if an app user attempts to edit or delete a record that is restricted by security filters. Previously, no alert message was issued. New: Deployed to all users. Previous: Deployed to 100% of free users and 50% paid users.

?

SkrOYC

@1minManager wrote:

An alert message is now issued if an app user attempts to edit or delete a record that is restricted by security filters

The thing is, Security filters should completely avoid seeing the record inside the app, so if they can see the record, they should be able to do whatever they want, that's the point of a Security filter, right?

For Adds/Edits/Deletes we have the "Are updates allowed?" option that has nothing to do with Security Filters. Maybe the team got confused @lizlynch

Anyways, thanks for taking a look at it

Rifad

Looks like they are confused about how it works and mixed security filter with updates.

Rifad

I have been asking on multiple post about this issue and no response yet. But this is going to make issues in many of the apps.

January 28, 2023 - Google Cloud Community

January 25, 2023 - Google Cloud Community

January 24, 2023 - Google Cloud Community

Luke_H

Please appsheet team, escalate this issue and roll it back. We keep getting this error as well.

EliK

@lizlynch I am confused what the intended use case of the security filter warning is, and it seems others are confused as well.

I use security filters in my apps to limit access to records. If the security filters don't allow access to the current user, those rows are not included in their version of the app at all.

When would this security filter warning be useful? Does anyone have a use case?

Rifad

Must be a misunderstanding or lack of knowledge how AppSheet works.

SkrOYC

@EliK wrote:

Does anyone have a use case?

0️⃣

OptimiX_XcrY

i hate this. You should tweek this so it only starts it's effect after the sync is done or after the current view of the current row is changed.

For the community, this happens when I change something in a row that makes that row violate security filter (usually by quick edit columns) , before I change my screen. And it happens many times a day for my users. I have to teach every user to hit cancel, then go to menu, cancel modifications, refresh again,... Not cool.

I have a task app , with quick edit dropdowns, one being for assigning a department...and when I hit the wrong department, I immediately corect it by choosing the right one.

This is not the case anymore,because I get the security violation messages. And some users keep working in app without noticing...and when a lot of changes are unsynced and they notice...well, that's when they discard all changes and all recent work

SkrOYC

Try using a browser, you will get a better explanation of the error. Then modify the expression used for a security filter by optimizing it.

I did it and the "security filter violation" is not giving me problems now.

Sai1

Hello,

So sorry about the inconvenience caused. The intended use case being "If the user locally created a new row with initial values that don't pass the filter condition". Again, we are working to make sure we address all the edge cases which are valid but are unfortunately classified as a violation. To address this, we are adding accounts to Exclude list for the time being. I sincerely appreciate your patience.

Thanks so much,

- Sai

Luke_H

Could you please add our account to the exclude list. We are still experiencing the violation.

takuya_miyai

@Sai1
We are having trouble with this happening with our clients.
I would like to be added to your exclusion list.
Would you like me to send a DM to you?

Please note that support is not likely to be able to accurately understand this complex event.
We would like you to prepare a contact person who understands the content.

@devingu
@Koichi_Tsuji

Sai1

@takuya_miyai : Happy to help. Please feel free to message me to be added to the exclude list too.

- Sai

sparkmedical

Hello, Can our account please be added to the exclude list also?

SkrOYC

@Sai1 wrote:

"If the user locally created a new row with initial values that don't pass the filter condition".

Notice that we may have a security filter on "false" just so that users don't see any rows but could add them

Jonathon

A client of mine is having issues with this now, with a really basic pseudo delete scenario:

ISBLANK([deleted])

When you pseudodelete, there is generally a ~5 second period where the record hangs around before the security filter catches up and removes it. In this case the user attempted to delete it twice, and the second delete was triggering the error.

SkrOYC

@Jonathon wrote:

When you pseudodelete, there is generally a ~5 second period where the record hangs around before the security filter catches up and removes it

Btw, you could try adding a Slice with the same ISBLANK([deleted]) (and use it instead of the table) and the result should be instant inside the app, although a little cumbersome to have one slice per table with this setup

SkrOYC

@takuya_miyai wrote:

support is not likely to be able to accurately understand this complex event

Didn't saw that coming...

Steve

Only a small handful of the AppSheet developers have experience developing real-world apps with AppSheet, so they have a huge blind spot for how AppSheet's features are applied. Release-and-see-who-complains is a big part of how they discover real-world use cases. A primary purpose of free accounts is testing and discovery.

OptimiX_XcrY

Half of my colleagues are trying to kill me today, because half of them are violating the security filter again, it happened today more often than all of last week

QREW_Cam

I'm experiencing this same issue but on an Add, eventhough the release say its for 'edit or deletes'. An alert message is now issued if an app user attempts to edit or delete a record that is restricted by security filters. Previously, no alert message was issued.

I get that the user may have added a record with a start date prior to 7 days ago, but Security Filters have never restricted adds. I get that the record would not be passed to the app in a sync, just weird that it seems like security filters are working almost as if it's a hidden 'Valid If ' that's only enforced via a sync error.

ahmedTaj

I had a similar problem, to resolve this, please go to the excel sheet, then ROW Key ( the one you hide it), and delete the updates done from the user, it will be cleared.

Koichi_Tsuji

I dont think this is a solution for widely-spreading out flu..... like this.

ahmedTaj

It's a workaround, shouldn't be a permanent solution .

JaimeAxt

Same problem here since yesterday... my apps are in production and worked well until yesterday...

Steve

This is a complete change to security filter semantics, and reflects either a lack of understanding by the developers of what security filters are OR an intentional and unannounced intent to redefine the feature.

SkrOYC

Both?

Fabian_Weller

Hi @Sai1 we now also got in trouble with the change to the Security Filter you made. This is the scenario:
In Security Filter we use the expression: [DateTime]>=TODAY()-10 to load only data from the last 10 days.
A user makes changes and closes the app before sync is done. (Of course a user should always wait until everything is synced, but you know that this happens.)
It's Friday and the next 2 weeks are holiday. After that the user opens the App. The App tries to sync but cannot. Because of "Security Filter Violation Detected".
It tries to sync an edit of a row that is no more available to the user.
How could we handle this?

SkrOYC

@Fabian_Weller wrote:

How could we handle this?

I think we should push the team to just change their minds around this nonsense. Really, in which ways security filters should be mixed with "Allow updates" kind of permissions? That's why we have both, right? In your use case, users should be able to upload those records and then they won't be able to see them, simple.

As I already said, it's like using a security filter with "false" to prevent users from seeing the data but allow them to upload it. Why should this simple use case be changed, for example?

Koichi_Tsuji

Yes, agree. What a nonsense.

Koichi_Tsuji

Im not sure why they keep feeding the new headache to us by introducing such a non-sense. I m fully fed up and tired.

EliK

@Koichi_Tsuji and @Fabian_Weller I agree. Although most of my apps aren't affected (yet) by these security warnings, I do wish the Appsheet team would take the consideration the opinions of such senior members of the Appsheet community (such as @Steve) and consider that this change is a fundamental shift in the function of an existing feature, which is affecting many existing apps. It's unacceptable.

Further, I still don't understand the use case of this error to begin with. That's what "allow updates field is for". If you really want, then put a warning if a user tries to update a row that they aren't allowed to. But that would be redundant, since the edit button simply wont appear for them...

@lizlynch can you make sure to pass this feedback on to the Appsheet team? You have always been very helpful in bridging this gap between the devs and real life Appsheet users.

Thank you so much for your help.

Koichi_Tsuji

Honestly, I m perfectly not sure from where "allow updates field is for" type of idea is coming from.

But reading its name, I simply guess that : -

- You have a table where you apply security filter, meaning some rows which reside on the actual data table will be ruled out by such.

- When the user enter data (newly) from AppSheet, then such a new row will be ruled out by security filter conditoin.

- If this new row is saved, then app users will not see such a newly added row over the appsheet app. As they are ruled out.

My assumption was the AppSheet will be alert the message and post it users. "Are you alright to save this form, although it will be filter out by the security filter conditions your app owner defined. Even you save this form, you will not see in your app? Are you okey?"

Very complex for app users, if this story and assumption is true.

But for now, we only get the new ERROR which make the app un-use rather than we get simply alert which will not affect the seamless usage of our apps. Very much annoying.

Koichi_Tsuji

I just want to know from where this idea is coming from.... If someone requested and AppSheet take it out, then what is the purpose it? Hope AppSheet team give us a clarity.

lizlynch

@EliK - Thanks for the ping. Just FYI, the issues raised in this thread have been escalated.

EliK

Thank you @lizlynch

Bug: Security filter violation?

Rollout changes

0️⃣