New Bug Encountered: Editable_If affects update of column through Action run by Report

Reviewing documentation for Editable_If, below is the described scope:

The Editable_If column constraint only affects the user's access to the column value, such as when the
 user interacts with a form view containing the column. The constraint is also checked before allowing
 access to Quick Edit columns, such as in detail and table views.

Editable_If does not affect the application of app formulas and initial values, the performance of actions,
 or any other app behaviors.

This meshes with my person expectation of when Editable_If is applied.

However, when I run a Report rule to change the value of a column, the change is prevented with the following error message:

"Action Name": "Update Escalation Column",
"Errors": "Error: Perform DataAction 'Escalated to Level1' failed because Row having key 'a77b7788 : 
ffa97ab0: 5fca42e8' in table 'Activities' in field 'Status' 'Editable_If' condition returned 'false'.",
3 Likes

@WillowMobileSystems
The situation is the same with the AppSheet API as well. Provided you have editable_if, reset_on_edit or valid_if conditions, they are obeyed and flags an error.

1 Like

Ah, inconsistencies!

You could use "Server" = CONTEXT("Host") in the Editable_If expression, perhaps?

2 Likes

Yes I do plan on using CONTEXT(). I didn’t realize we could test for “Server”.

From the standpoint of the article, I think this is a bug. Maybe the design changed?

This may boil down to a matter of preference. I prefer the Editable_If only apply to the views and not the automation. I believe that developers will know when automation should/can update AND can control it when needed. A developer cannot control a users action.

3 Likes

Escalated.

2 Likes

I believe now that there was a conscious decision to modify the design of Editable_If. I have recently returned to some previous apps and found that the key columns now have this expression in Editable_If: ISBLANK([_this]) . I am 100% certain I did not insert these expressions.

Key values were only one common place to set a column as not editable (but still allow automation to set it upon adding of new rows). A second common place I am encountering the need to 'workaround" the new Editable? design is for status columns where only certain roles can change the status.

For me, for the types of apps I’m building, this design change on Editable_If is a step backwards. Not only do I now need to add “workaround” expressions to get the same functionality as before BUT I also need to double testing efforts of that feature to make sure the automation CAN change the values i.e. - no bugs in the expression that prevent it.

2 Likes

Any update on this?

I think I’m facing the same problem.

I have a workflow that run 2 actions:

  1. Save file: generates a PDF
  2. Sets the file’s path in a column called “VIR No.” (this field should not be editable so i set editable_if=FALSE so that only actions can update it).

But when I check the audit history to check why the file is created but column doesn’t get updated, I see this error:

“Errors”: “Error: Perform DataAction ‘Set VIR File full path on Weld’ failed because Row having key ‘d878c898 : 8’ in table ‘Welds’ in field ‘VIR No.’ ‘Editable_If’ condition returned ‘false’.”,

You can by pass the Editable_If check for your Workflows by including in the expression

CONTEXT("Host") = "Server"

That’s what worked for me. Thanks to @Steve for this suggestion in another post.

3 Likes