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 7 339
7 REPLIES 7

@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.

Steve
Platinum 4
Platinum 4

Ah, inconsistencies!

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

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.

Escalated.

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.

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.

Top Labels in this Space