Scripting block: hide "edit code" button to editor-only users. (non-owner/creator)

[Seb_Meunier]

Hi,
I’m experimenting the scripting block to provide a simple UI (2 buttons) for non technical users of this base to make an HTTP request when they’re done editing the base.
I couldn’t find a way to provide them with the UI of the script without having the “Edit code” button that opens the source code of the script.
Is this possible?

Thanks

Seb

[Bill_French]

Hi Seb, and welcome to the community!

Seb_Meunier:

a simple UI (2 buttons) for non-technical users of this base to make an HTTP request when they’re done editing the base.

Have you considered using an action script instead? This would allow you to move records into a view when they change and where the action script simply runs based on this event. Doing so isolates the scripting activity from the users and they don’t have to actually do anything when they make changes. Just an idea…

Seb_Meunier:

a way to provide them with the UI of the script without having the “Edit code” button

This is a good question - don’t know actually. Someone here knows and I’ll bet it’s @kuovonne or @ScottWorld who knows all things security-related.

[Seb_Meunier]

Hi Bill!

I did consider the action script, but

1. I’m a free user :slightly_smiling_face:
2. I don’t want to automate the call to this HTTP request based on a record change. That was actually my initial thought but ended up being a bad idea, at the user level. In this scenario, the user would update multiple records, review them, and when done click the “Go” button on the UI to push these modifications to the HTTP API behind the scene.

I just don’t want them to play around with (= break) the script code.

[ScottWorld]

Seb_Meunier:

a way to provide them with the UI of the script without having the “Edit code” button

Bill.French:

This is a good question - don’t know actually. Someone here knows and I’ll bet it’s @kuovonne or @ScottWorld who knows all things security-related.

Ah yes, this issue has been brought up before — as far as I know, the only way to hide the code from your collaborators is to create your own custom block. I believe that this shields the user from the scripting code, but @kuovonne would know for sure.

For a non-JavaScript solution to this issue, the way that I usually have my users make their HTTP requests is by clicking on a button in Airtable which then triggers an HTTP request via Integromat. So they never have access to any of the code, because it is hidden away from them at all times. (If you need a consultant to help you setup this sort of a scenario, feel free to send me a private message.)

[Bill_French]

Seb_Meunier:

I just don’t want them to play around with (= break) the script code.

Yep - I get it.

@ScottWorld’s approach is one way, and a Custom Block is another. Script Blocks (I believe) are unprotectable.

[Seb_Meunier]

I did some quick tests with Integromat (and IFTTT, and Zapier, …) but I guess I’ll just sound like an Airtable “blocks” (or not in fact) newbie (which I am) with this question: when you say “clicking on a button in Airtable”, do you mean adding a button as a field in a table ?

Actually, I never noticed until now you could have a button in a record…

Doh !

[Kamille_Parks]

Chiming in to say yes, Custom Blocks don’t show the code to any collaborators. But since OP says their a free user, I must point out that both Scripting Blocks and Custom Blocks will become pro-features in the near future. While I believe Automatons will be available for everyone, Script Actions (with Automatons) will also become paid features if they aren’t already.

[Seb_Meunier]

I think having a button in a single record in a dedicated “control table” in this base works for me, as the URL to call is a static one and the API call can be a GET with query parameters.

Thanks Airtable community for your quick help !

[kuovonne]

As others have pointed out, it isn’t possible to hide Scripting block code from any user, and it isn’t currently possible to prevent users with editor permissions from changing Scripting block code. (I’m hoping that Airtable will adjust its permissions settings so that only creators can change scripting block code.) Scripting block code requires a button click to run–either the run button in the scripting block itself, or a button field in a table.

For automations with scripts, editors can view the automation script, but cannot edit the automations script.

If you have a custom block, only the person installing the block in the base has access to the code, and pushing code changes to a custom block is far more complex than changing code in Scripting block.

@Kamille_Parks also pointed out that free users will have access to Scripting block only “until September”, so you will either need to upgrade your workspace to a Pro subscription or a third party method of running code (such as @ScottWorld’s suggestion.)