Google Workspace Add-on for Google Drive, which uses AI to recommend new names for the selected Doc in Google Drive by passing the body of the document within the AI prompt for context.
Tired of staring at “Untitled document” in Google Drive? At Google Cloud Next ’24 and I/O 2024, the Google Workspace DevRel team showcased new Apps Script samples utilizing the Gemini API for AI-powered functionality.
One such sample, “Name with Intelligence” by Charles Maxson, helps developers overcome this common hurdle. This Google Drive add-on leverages the Gemini API to suggest relevant titles for your documents, saving you valuable time and effort.
This innovative Google Drive add-on tackles the common struggle of naming untitled documents. It utilizes the Gemini API to analyse the content of your Google Doc and suggest relevant titles based on its understanding of the text. This not only saves you time brainstorming titles, but also ensures your documents are clearly named for easy searchability later.
For those interested in my GeminiApp library, you can also find the sample here.
Take Your Development Further
This is just a glimpse of what’s possible with the Gemini API and Apps Script. With a little creativity, you can develop your own AI-powered Google Workspace add-ons to streamline your workflows and boost your productivity.
I encourage you to experiment and create innovative solutions that enhance your Google Workspace experience!
Forget everything you know about deploying Google Apps Script, because the typical ‘Deploy’ button is not part of our strategy.
TLDR;
In the previous posts in this series, we focused on preparing our tools and setting the stage. We reviewed our project’s functionality, explored the project structure, and delved into the source code. We also discussed the pros and cons of using JSDoc versus TypeScript and covered essential developer tooling.
Today, we’re finally getting to the fun part—deploying something! We’ll start by deploying our library as a native Google Apps Script library. But there’s a twist: we will do it the proper CI/CD way, avoiding the typical “Deploy” button in the online IDE.
Side note: I always avoid the online IDE as it feels like my hands are tied when I use it.
Instead, we’ll use Vite with a custom plugin to bundle our library and GitHub Actions to handle the deployment.
About a year ago, a notable shift occurred in the developer community when SvelteKit made the decision to transition from TypeScript to JSDoc, specifically stating that TypeScript was not the ideal choice for developing libraries. This move definitely raised some eyebrows and stirred the pot among developers. Initially, I was skeptical, perceiving it as a regression rather than progress. TypeScript was even featured in one of my previous blog posts as a recommended tool. However, this decision began to resonate with me over time, leading me to adopt a similar approach in Google Apps Script. The reasons for this shift are manifold, with some being universally applicable and others specific to the peculiarities of Apps Script.
Here are the links to the repo and the NPM page again.
Let’s dive into why TypeScript was chosen in the first place and what has changed to endorse JSDoc over it.
Following up from last week, we get into how I built the table() method in our ConsolAS class, using test-driven development (TDD). This is a cool way to make sure everything works perfectly by testing each part before we fully build it. We’re aiming to make it work just like the console.table() function in Google Chrome, which is pretty handy.
Apps Script class that provides equivalent methods offered by the built-in DriveApp, but that does not require use of full ‘/drive’ OAuth scope (which is a “Restricted” scope”). Instead, uses only these Recommended (non-sensitive) and/or Sensitive scopes
When you use OAuth 2.0 to get permission from a Google Account to access their data, you use strings called scopes to specify the type of data you want to access on their behalf. For Google Workspace Add-on developers wanting to distribute your app in the Google Workspace Marketplace one consideration is only using the scopes required for your app. In the case of Google Drive a number of the scopes are classified by Google as “restricted”. To use “restricted” scopes there is an enhanced verification process, which requires Cloud Application Security Assessment (CASA) by an independent security assessor, which come at a cost and can be time consuming.
ReDriveApp is a new Apps Script community library published by Dave Abouav which makes it easier for developers to use reduced recommended scopes for integrating with Google Drive. As explained by Dave:
The built-in DriveApp service is an easy and powerful way to interact with Google Drive in your Google Apps Script projects, which is why so many developers make use of it. It’s one downside is that it forces your project to use the full ‘/drive’ OAuth scope, which is a “Restricted” scope.
In many cases though, projects don’t really need the full /drive scope for common tasks, and the Recommended /drive.file scope is sufficient. This allows your project to create new files, and open existing files if authorized by the end-user via the Drive Picker. Using it also avoids the aforementioned security review, and is less alarming to users when authorizing your app.
ReDriveApp is still work-in-progress and not an official Google project. There are a number of methods that still need to be implemented, but the project is open source and can be contributed to on GitHub. If you are planning or have already developed a Marketplace Add-on that has stalled due to enhanced verification for restricted scopes it could be worth looking at and contributing to this library.
Retrieving and saving properties in Google Apps Script can be slow, especially if there are a lot of them. SpeedStore is a blazingly fast in memory properties store which you can use to make retrieving and saving properties much easier.
Continuing yesterday’s theme highlighting some of the components for developing a Google Workspace Add-on where John McGowan highlighted how Properties Service can be used to store and use a “licence” property to customise your add-on UI, we continue by looking at how you can handle property storage.
There have been a number of community contributions in this area such as Bruce Mcpherson’s bmCrusher. Another option is SpeedStore from Joshua Snyder. Not as feature filled as bmCrusher but the benefit is the library is more compact. SpeedStore still comes with some very useful features including automatically handling properties over 9kb and JSON encoding/decoding. Perhaps the biggest benefit is speed particularly when you are using a single store for all your properties.
📅 A free and open source web app to make it easy for others to schedule with you –
Features
🌐 Create a unique link that others can use to book an appointment on your Google Calendar
📑 Offer mulitple types of meetings, each with their own configurable timeframe and event settings
📒 Place events on any calendar you have edit access to
📆 Confirm availability against multiple calendars
🤖 Intelligent suggestion of available free times on both your and (if accessible) the scheduling party’s calendar
🔗 URL parameters to bring the user to a specific meeting type and prefill their email1
⚡ Send a webhook push to integrate with IFTTT, Zapier, and more when an event is scheduled
🌈 Configurable accent color
🌙 Automatic light and dark mode
💳 No premium tier. 100% free.
This Apps Script solution comes thanks to a tweet from Sourabh Choraria (@choraria) highlighting a open source project from Leo Herzog which lets to deploy a highly customisable Google Calendar appointment scheduling app. The solution uses a nice JavaScript library for handling dates/times which you might find useful to include in your own projects called Luxon.
Since Google Apps Script was released on August 19th, 2009, it is used by a lot of users. By this, now there are a lot of useful libraries of Google Apps Script (GAS) in all over the world. But when I want to search a GAS library, I always use Google search engine. Unfortunately, in the current stage, the libraries cannot be directly searched by a database. On January 11th, 2020, a proposal for the database of Google Apps Script Library has been proposed by Andrew Roberts. When I have discussing about this with him, I thought that I tried to think of a sample database. So I prepared this…
Google Apps Script turns 13 years old today and in celebration we are highlighting this combined community contribution. As you will see from the source repo commit history this searchable database of Google Apps Script libraries has been around for a while, but given what it represents we thought worth celebrating.
All PDF settings including colontitles = custom headers and footers.
Input parameters is a single plain object.
The library uses the printing features of Google Spreadsheets to provide a complete representation of a document in a different format. It contains a huge amount of features There are settings such as page size, headers and footers, colontitles, gridlines, notes and more.
Some ideas are bad, and then sometimes there are ideas so bad they actually go back around to being genius — we think we’ve come across one of those. Yes! We have an end to end blockchain working entirely off of a google sheet: transaction broadcasting, mining, wallets, gossip — all of it! ShiitCoin is (obviously) a troll project not meant to be rEaL mOnEy 💴 but we’re hoping to farm some internet points there’s some educational value to exploring the barebones of a blockchain which we’ll share here.
In pre-pandemic times I used to give a talk entitled ‘..you can do that with Apps Script’, which includes some more of the extreme examples of projects people tackle with Google Apps Script. This project by nalinbhardwaj (Nalin Bhardwaj) and Adhyyan1252 (Adhyyan Sekhsaria) definitely falls into the fun/interesting category and who knows you may find some interesting code snippets in the associated Github repo that might be useful … but no guarantees.
