Expression bug - NOT(IN([_THISROW],TABLE[ID]))

[Koichi_Tsuji]

We are observing another new expression related potential bug.

This is one of the standard AppSheet expression

NOT(IN([_THISROW],TABLE[ID]))

This syntax is quite often used when we inspect if the data entry to app is either 1) Add new row or 2) edit the existing data through the form view.

We have bunch of use cases of this expression , where we push expression into IF condition to the action. Then set this action to be fired on saving the form view.  When the new data is entererd through the form, then this action will be fired. Once the record saved and in turn the edit the data from form view, then this expression return false, so the action is never invoked.

However, currently we are observing the action never gonna fired in any case.

Obviously this is a bug.

I tested with free and enterprise acocunt, but the results were the same. 

@takuya_miyai 

@Suvrutt_Gurjar 

@Steve 

[Koichi_Tsuji]

It is strange enough. Removing NOT() expression from outer expression.

IN([_THISROW],TABLE[ID])

Set this expression for IF condition of action. 

Set action to invoke on save event for the Form view.

Action is always fired, regardess of new or old data.

Definitely something is going wrong.

[harsh-google]

Hi there, do you know the date of filing the issue with support? I am trying to locate the issue internally but can't seem to locate it

[Koichi_Tsuji]

Unfortunately no response from Appsheet for this massively impacting bug.

No update from formal supprort route as well. Dissapointing.

@Steve 

[Steve]

Escalated.

[Adam-google]

Hi Koichi, I looked into the timing with this. When adding a new row, before the form is saved, I find the IN expression returns false (the form-in-progress does not yet appear to be in the table). I could verify this with an AppFormula column. Upon saving the form, the new row is added to the table and the add request is queued, and only after that succeeds do we decide whether to run the action or the default navigation. At this point I would expect the row to always be visible to any lookup expressions associated with the action, which is consistent with what you're seeing. I tried running an older build from the beginning of March and found the same behavior, so it doesn't appear that this has changed recently.

To make the action conditional on the form being an add or update, you might need to put the expression on an AppFormula column so it gets evaluated before the form is saved, and then reference the column value in the action condition.

[Koichi_Tsuji]

QTE

I tried running an older build from the beginning of March and found the same behavior, so it doesn't appear that this has changed recently.

UNQTE

As far as our record is concerned, this is false.  It used to work definitey. We have record of filing as we demonstrate while our onlne course to our clients before.

This trick was introduce by @Steve years back, and we set this expression in action (conditional action to be involed with this expression) and it used to work. The reason I brough this thing up on this occassion is this is no longer working...

If your team decide, the behaviror has been the same as before. Then i have no control to pursude you.... Very sad.

Yes, if we push this expression into VC, and we refer to this VC inside the action condition, it works. I m not talking about the work around....

Problem seems to me for now Appsheet Dev teams are not able to track the records of the changes made, which affects the existing behavior. It is a risk to us to use Appsheet as business daily solutions. 
Apps are working fine. All the sudden, show the odd behavior. Asking to support to check. Then answer is no change since before.

it is tons of risk with us to use Appsheet as app will start to work unexpectedly all the sudden. And we don’t get problems rectified at the end. 

[Koichi_Tsuji]

We are serving to one clients (with 20k appsheet users).

Can you imagine how the impact is going to be ?    Until yesterday, the app is working fine. Then today we see problems. Before we report such errors to AppSheet teeam, we spend hours and days to repro. And once we confirm the error is surely there, then we formaly report to your team. 

Then answer is slow. At the end, no solutions, as Appsheet team not admiting this is a problem.

we have to be speachless to our clients....... 

The only thing we can say to client is "this is what it is....."  Does not make sense.