Permissions that allow changes only through code

[jowan_qupty]

Hi all,

Wondering if anybody knows of a workaround that allows one to set user permissions to only allow changes (edit / create / delete record) through code (scripting block in my case).

This would come in very handy when you don’t want base users to mess with the content or structure of your base, but would still allow them to add/edit/delete records through the scripting block, therefore enforcing your desired business rules.

@Airtable Team, any suggestions? should we expect this feature in the near future?

Thank you,

[ScottWorld]

I agree that this is important, and this is one of the big missing features in Airtable. Currently, businesses use Stacker for this, which is an excellent app.

[Kamille_Parks]

I made a Product Suggestion for this very thing:

Field Permissions: No edit privileges except for Scripts/Blocks Product Suggestions

Certain blocks require users add an editable (non-formula) field to a table to hold misc data which shouldn’t be directly edited by the user (i.e. the Map Block requires a geocache field). Many Script Block scripts semi-automate or standardize data entry processes to provide a form of data validation or workflow integrity. I think it would be nice if Airtable’s field permissions included a toggle for " Allow this field to be set in scripts/blocks/API" when the field permissions are set to: “Who…

[Bill_French]

jowan_qupty:

This would come in very handy when you don’t want base users to mess with the content or structure of your base, but would still allow them to add/edit/delete records through the scripting block, therefore enforcing your desired business rules.

I’m not really up to speed on the newly released cross-base sync feature, but I believe this is now possible.

Given that a base can provide a constrained (read-only) view of an authoritative data table, but also allow script blocks to create transactions in a read-write table, it should be possible to provide a pathway for edits to make their way back to the authoritative base.

The objective is to insulate users from direct edits of the data by providing a proxy transaction layer. The script block would be responsible for reading the replica data and writing transaction instructions into a table that is then synced back to the authoritative base. As new transactions occur, a script action fires up to update the authoritative data.

This approach has many unseen advantages as well including but not limited to …

• The ability to perform update validation.
• The ability to perform complex change commits across relational tables.
• The ability to log transactions and create change metrics.
• The ability to apply other update constraints based on user identities.

Think this idea through and share your thoughts … I think it might work pretty well.

[jowan_qupty]

@ScottWorld, I have already attempted to do just that, but unfortunately the lack of real-time data syncing between Stacker and Airtable, as well as the inability to embed the Airtable Scripting block (or custom block) to Stacker makes it quite useless in this use case.

@Bill.French Thanks so much for the explanation, i will test it and let you know how that works for me.

However, i still think that @Airtable should develop this relatively very simple permission feature, which in my opinion has a lot of use cases and should attract many enterprise customers.

[Bill_French]

jowan_qupty:

i still think that @Airtable should develop this relatively very simple permission feature, which in my opinion has a lot of use cases and should attract many enterprise customers.

Yes, as do I…