- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 03:24 AM
Hi all,
I’d like to know if there is a way in a Scripting app to check if the script was called from the click of a button in a column or via the Run button on the Script app itself.
My use case is that we ideally want one script that can be used either for a single record (the button column scenario) or an array of records (which we would fetch & manage in the script itself).
Basically the first if
statement in the script would check this, and then the code would branch accordingly. Sample code to demonstrate the idea:
let table = base.getTable('Orders');
if ('button was clicked') { // <-- How to make this check??
//process that row only
let record = await input.recordAsync('Pick record',table );
} else {
// process records from a table or view etc.
let records = await table.selectRecordsAsync();
}
Thanks in advance for any suggestions!
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 08:59 AM
As @kuovonne said, there isn’t. This is an obvious oversight that the designers should have considered. Lacking this capability, there is a way to get there and it’s yet another in the long list of Goldbergian buffoonery that more often than not, pervades the realm of Airtable solutions.
- Create the button and have it call a script block (A) that does one thing - and only one thing. It sets another field (like a checkbox).
- Create the script block (B) that when “Run” manually, it looks for any records where the checkbox is enabled and processes only those records selected (there should be just one as the next item will reveal).
- Create an action that fires script block (B) when – and only when – the checkbox has been enabled for a single record.
Steps 1, 2, and 3 resolve the first condition - i.e., when the button has been selected. Now we’re on to the second condition - when Script Block (B) is run manually.
- Process all the records when – and only when – no records were checked.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 06:58 AM
No, that currently is not possible.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 08:59 AM
As @kuovonne said, there isn’t. This is an obvious oversight that the designers should have considered. Lacking this capability, there is a way to get there and it’s yet another in the long list of Goldbergian buffoonery that more often than not, pervades the realm of Airtable solutions.
- Create the button and have it call a script block (A) that does one thing - and only one thing. It sets another field (like a checkbox).
- Create the script block (B) that when “Run” manually, it looks for any records where the checkbox is enabled and processes only those records selected (there should be just one as the next item will reveal).
- Create an action that fires script block (B) when – and only when – the checkbox has been enabled for a single record.
Steps 1, 2, and 3 resolve the first condition - i.e., when the button has been selected. Now we’re on to the second condition - when Script Block (B) is run manually.
- Process all the records when – and only when – no records were checked.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 09:31 AM
But this doesn’t actually have a single script that detects if it was run from a button field or from the script app. It lets you reuse the code for one script in two places, but actually involves three scripts (one for setting the checkbox, one for running from scripting app, and the automation script.)
I suspect that you don’t expect anyone actually try to implement this “Goldbergian buffoonery”. There are too many reasons why this seems like a bad idea.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 10:25 AM
The number of reasons this is a bad idea is irrelevant. It works.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 10:36 AM
Yes, I agree that it would work. But I fail to see how the pros would outweigh the cons.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2021 02:38 PM
I think you’re overthinking this - we all agree it’s not possible to do it right, but it is possible to do it. I think the customer - like many others building convoluted processes - will probably choose to use this or some other level of complexities that just get the job done.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 11, 2021 03:06 AM
Hi both, thanks for your thoughts and suggestions on this. It’s good to know both a) that it’s not possible using ‘out of the box’ functionality, and b) that there’s a potential workaround :slightly_smiling_face: