Another in the SuperFetch (a proxy for Apps Script UrlFetchApp) plugins series, Frb is a plugin to access a Firebase Real time database.
If you want to take your use of APIs a little further Bruce Mcpherson is continuing his series exploring his recently published SuperFetch library showing how a client can be setup to interact with Firebase. As Bruce highlights: “Firebase is pretty fast, so there’s not a huge speed benefit from caching, but if you’re on a pay as go plan, SuperFertch caching can reduce your Firebase costs.”
The source post provided by Bruce provides everything to need to set up the SuperFetch client and Firebase project.
In this article, we’ll go over the different ways a GAS script can relate to the user using it, and show an easy way to dynamically resize dialogs built using the Apps Script HTML Service. To achieve this, we will introduce some basic concepts related to the object model of HTML documents and their manipulation using JavaScript. – [Google Translated]
A couple of community contributions for custom dialogs have landed in the Pulse inbox recently. The official documentation on Dialogs and Sidebars in Google Workspace Documents is an excellent starting point, but if you prefer learning from video tutorials Chanel Greco has recently published Google Apps Script Alert – Deep Dive on the saperis YouTube channel.
If you’d like to go a little further this post from Pablo Felip details how custom dialogs can be dynamically resized using the methods in google.script.host and client-side JavaScript (for non-Spanish speakers you’ll have to view this post via Google Translate).
Many of us undisciplined hacks (read: not professional developers) sometimes find ourselves wondering when we will buckle down and start using Github to store our Apps script source files and versions.
If you sometimes find yourself in the same boat: needing to restore or access an old script version, the first thing you probably do is revert back to the old Apps script editor (IDE), (filling out the form regarding the lack of version history as your reason), and then hoping the version queue goes back far enough for you to recover what you need.
Well, today my undisciplined friend, I will show you a way to recover your script files, all the way back to version 1!! Yes, no more switching back to the old code editor.
In Pulse we’ve previously highlighted Romain Vialard’s solution to Retrieve previous versions of Google Apps Script projects, which uses UrlFetchApp to make a call to the Script REST API and add recovered files to your Google Drive. In this new contribution from Clark Lind a clever ‘no-code’ solution using Google’s interactive API Explorer. The post includes all the steps you need to follow if you need to recover an old version of a script project.
In this post, we’ll be going through a quick workaround so that you can get back to running your scripts. Note that this issue is still not entirely resolved, but you can follow any developments in Google’s issue tracker.
If you are a Google Apps Script developer using a consumer @gmail.com account for development/testing or sharing script projects for other users to use with their gmail.com account you may have encountered the “This app is blocked” issue. This issue appears to prevent a Google account from completing the Apps Script authentication flow even when using limited scopes.
This post from Aiman Fikri provides a solution for getting around this issue by associating an Apps Script project to a Google Cloud Platform (GCP) project. Google also provide documentation on setting up Standard Cloud Platform projects, but if you are supporting novice users directing them to Aiman’s post might be less daunting for them.
There are some benefits of using Standard GCP project particularly when you are developing scripts as it gives access to Cloud logs and Error Reporting. If you encounter “This app is blocked” on all your script projects you can group multiple scripts with a single Cloud Platform project to save having to go through the full setup process.
Fortunately, Kanshi Tanaike has been exploring the impact the increased volume of data in Google Sheets has when using Google Apps Script and both SpreadsheetApp and Sheets API. The linked report contains a number of useful findings and strategies for handling large Google Sheets with Apps Script.
Behind the scenes look at what went into creating an Apps Script-native Add-on to generate Webhooks for Google Sheets. ICYMI: You can access the add-on from this link and know more about what it does here
It’s worth checking out Sourabh Choraria’s latest Google Sheets add-on which enables users to quickly setup a Google Sheet to receive data from other services which support the creation of webhooks. As part of this solution the add-on makes extensive use of the Apps Script API, which can be used to programmatically manage Apps Script projects including deployments. This post from Sourabh highlights some of the key endpoints used in the Apps Script API as well as a number of lessons learned about deploying web apps for users.
This is a sample script for retrieving the summary of Google Document using Google Apps Script. Recently, a blog of Auto-generated Summaries in Google Docs has been posted. I thought that this is very interesting function. I thought that when this function is released, checking each summary of a lot of Google Document will be much useful for simply confirming the document content. And also, I thought that when all summaries can be retrieved using a script, it will be also useful. In this post, I would like to introduce to retrieve the summary of Google Document using Google Apps Script.
There are a couple of pieces of interesting information highlighted by this post by Kanshi Tanaike that caught my eye . First, useful to have a reminder that Google announced automatically generated summaries in Docs in February 2022. This might be a premium feature for the paid Workspace accounts as like Kanshi I’m not seeing this yet in my own free Google Workspace domain. The bit that really caught my eye is Google Docs summaries are using the existing Google Drive description property, which means it is not currently available via DocumentApp or if using the Google Docs API as an Advanced Service Docs. I’m sure this will catch some people out and hopefully this post will point people in the right direction.
I’ve long been interested in using one of the big office productivity platforms to build an embedded add-on. For a solo developer it’s a no-brainer: the platform takes care of the requirements above, and when the platform has a marketplace, there’s even a ready to go distribution channel to take it to market! The only real reason I’ve resisted it so far is fear of the slog of platform approval processes and required collateral. In this story I’ll explain how I felt the fear and did it anyway 😀
Google OAuth verification and Workspace Add-on app review can be quite daunting the first time you go through the process. In this post from Gareth Cronin he shares his own personal journey getting his JIT Time Google Calendar Add-on verified and approved. There are some great tips and resources shared in the post including how to show the OAuth client ID in the add-on demo video submitted as part of the verification processes.
Senbei is a traditional Japanese cracker made of rice. It is a very tasty cracker that goes well with Japanese tea, but there are also huge Senbeis as big as your face. What do you do when you eat such a big cracker? Usually, you would crush them into small pieces before eating them. The same can be said for processing huge data with Google Apps Script.
HTML form file-input fields are not converted to compatible blob format when submitted. They are left in application/octet-stream format. The file-input fields are passed as application/octet-stream, so DriveApp.createFile(formBlob) does not work correctly … So the functionality provided by HtmlService is not consistent with the documentation
There was an annoying little Google Apps Script issue which meant when handling file uploads to published Web Apps some additional coding was required rather than just sending the file blob server side. Thankfully the open issue ticket for this has recently been marked and confirmed fixed.
