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?
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 …
Think this idea through and share your thoughts … I think it might work pretty well.
@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.