I've created a stock watch tool that I'd like to share with the public. It consists of an editable Google spreadsheet with an associated function that is designed to run on a regular schedule as a trigger to perform the notifications when applicable.
How can I deploy this so that it's easiest for novice users to take advantage of the tool? Do I have to explain to users how to set up their own triggers?
Or is there a way I can bundle it all together, even with the triggers such that all the user has to do is fill out the spreadsheet? Or does deploying as a webapp apply here at all?
The new add-ons for GAS don't support installable triggers yet ("But keep the restrictions in mind"), but the old sheets still do (well mine still work). But I can't imagine you can deploy anything via the old script gallery anymore.
So I'd update your script to programmatically create the triggers onInstall() and create a demo version of an old spreadsheet that users could take a copy of. Then keep an eye on installable triggers coming to add-ons when you can deploy it as one of them.
Related
I'm involved in a standards development group where the meeting invitations are sent out, not as calendar invites, but as Word docs. I've written a script that allows me to take the Word doc uploaded to Google Drive, and run the script to create an entry on a Google calendar that I maintain.
At the moment, the script is unpublished, and to run it on the docs I use the "Test as Add-On" function from the script editor. That's a bit cumbersome because I have to go through the selection dialog to select the doc I want to run it on. Additionally, in the new scripts editor, it won't be possible to delete old tests and so my test dialog will end up getting filled up with every run of the script I've ever carried out.
It would be much better if I could have the script available to me, and me only, from the Extensions->Add-Ons menu when I open a doc. The script is not suitable for general publication: it works only on docs with the exact format of these meeting notices, so it should only be run by someone who knows what they're doing, and it accesses a calendar that I own, so I don't want to make it public. But I would like to be able to put it into some kind of "deployed" state so that, as I say, when I open any doc when I'm logged in as me, the script is just available directly from the Add-Ons menu.
Is there any way to achieve this? Or is there an alternative approach possible to this general problem, of having a script that you want to run on multiple documents that you own without having to formally publish it?
One option to "test as add-on" without publishing the script as an editor add-on, is to use installable triggers instead of simple triggers. This triggers should be created by using code in order to avoid having to add any code to each spreadsheet.
If you are determined to take the publishing path you can set your add-on listing to be "unlisted", this means that the add-on will not appear on the Google Workspace Marketplace, people will need to know the installation URL to be able to install the add-on.
Other options:
If you have a Google Workspace account you could publish the add-on privately for your domain. If you don't have this account type or if this is "not good enough", you might make your Google Apps Script add-on publicly installable but limit its core features to be used only by you by making use of a dynamic custom menu. For details please checkout Editor add-on authorization
The dynamic custom menu might based on a setting depending on the user email address. To make this work, as the Session.getActiveUser() requires authorization to run, it can't be executed by simple triggers, but you might implement a workflow to save it or a flag, i.e. add an option to the custom menu to initialize the editor add-on.
Another option is to make the dynamic custom menu based on the spreadsheet structure and/or content.
References
Installable Triggers
Enable and configure the Google Workspace Marketplace SDK
Related
Google Apps Script: Dynamically creating spreadsheet menu items
Publish an add-on privately
I am trying to use Google Big Query in my App Script for a Google Workspace AddOn I have created. In my dev environment this all works fine as a separate function with a static query, however I need to make the queries dynamic based on values users set in particular cells of a particular sheet. To do this I think I need to use onEdit() type functionality.
However the documentation makes clear that I can’t use onEdit to make such requests that require authorisation so I need to use a trigger and this is where I am getting confused.
Looking at the docs for installable triggers this seems to be the way to go. However at the bottom re triggers in add-ons it says I need to follow a different method and points me to Manifest Triggers. However, at the bottom of Manifest Triggers section it then says In addition to manifest triggers, Google Workspace Add-ons can also use Apps Script installable triggers which takes me back to where I came from.
So do I need to use Manifest Triggers for an Add On or can I use an installable trigger via App Script? Or can I use either but certain use cases would suggest one over the other?
I have a similar question to both of the questions below. I have a script bound to a google sheets, and I use this sheet as template. However I'm looking for an option to not have to grant permission each time I copy the file.
From reading the answers in the questions below, I understand I have to publish a standalone script as an add-on.
However, reading this answer, I see that I need to create a Cloud Platform Dashboard and all bunch of stuff which looks pretty messy to me, such as google reviewing process. Again, it is only for personal use...
Is there a way I can privately publish it as an add-on, without having to go through all the process?
Thank you
What is the best way to create Container-bound Scripts that can be cloned?
Grant permissions on open for first time for a bound script in Google Sheets
If you don't want spreadsheet hook triggers like onEdit or button or anything else, You can use a standalone script.
A standalone script can be written, which loops through your spreadsheets doing what's needed based on a time trigger.
Adding to the already existing answer
Publishing a private add-on does not require going through the Google Review process, especially since it is for personal use only.
Therefore, the situations below do not require verification:
If you want to deploy the add-on solely for internal use which means that the add on will be used only by people in your Google Workspace or Cloud Identity organization.
If you want to use the add-on domain wide which means that the add on will be used only by Google Workspace enterprise users within the domain.
For the whole list of exceptions from the verification process, you can check this here.
Reference
OAuth API verification FAQs.
I have a Google Apps script (written in a Google Spreadsheet) that creates a separate calendar and events for it with respect to a university course and the university calendar. The GUI is a Spreadsheet form, which triggers the execution of my script. The script gets its input from the spreadsheet form entry.
The trouble I have is that I can't easily deploy my solution to other users. Yes, they can make a copy of my sheet/form/scripts, so that they can run it on their account. Several problems, however, result from this approach:
triggers don't get copied - this is because authorization to access local info (calendars, contacts, etc.) must be given by the users before a trigger is enabled. So users have to re-connect the form submission trigger to the Apps Script for it to work (this is not user friendly).
if I change the code of my apps script, the users are using a copy and won't see the changes.
The solution seems to be Google Web Apps, but from what I've read, I can't re-use the form-based GUI of my approach. Or can I?
Google Spreadsheet Forms have the advantage that they are very easy to create, and you can already specify what fields are mandatory, etc. I don't want to have to re-write all of this in a complicated GUI front-end to my Google Apps Script (Edit: even the GUI builder tool seems way more complicated than a Spreadsheet Form), yet I want other users to be able to create the calendars and events in their own Google accounts. Is there a way to keep my form, but have it hooked to a Web App version of my code?
Try adding the form on a google sites (intranet). This way, any user having access, will be able to use the form as it is. All logic you created will remain the same.
Creating a script however will allow the user to execute the script "under their login", thus enabling access to calendars, contacts......
I have one master spreadsheet and a number of copies. This master spreadsheet uses some scripting.
Is it possible to link all the copies of this master spreadsheet to the same script as in the master spreadsheet?
Objective:
changes in the scripting in the master spreadsheet are automatically used by the copies
aka: low maintenance
amleczko is right: you should use the new library feature in Google Apps script.
However, as of today, you won't be able to do exactly what you want (using the same script for several spreadsheets). What you can do instead is save a version of your script (Files > Manage Versions...), in order to create a library. Then, import this library in the other spreadsheets (Resources > Manage Libraries...). Switch on the "development mode" so every change made do the library will immediately take affect in the spreadsheets using this library. Otherwise, you will have to save a new version of the library for every change, and manually update the version number of the library in every spreadsheets using it.
The problem is, you need to write a script in every spreadsheets using your library, with skeleton functions like this:
function doSomething(){
myLibrary.doSomething();
}
best way is to publish as add-on, then install the add-on, it will appears in every spreadsheet you open. and you can publish as private, which only seen by yourself.
I think this has changed. According to Issue 40 starting from 22 May 2012 there is such a possibility. Please check:
https://developers.google.com/apps-script/guide_libraries
https://developers.google.com/apps-script/guide_versions
http://googleappsdeveloper.blogspot.it/2012/05/introducing-versions-and-libraries-in.html
It's not possible in this way that you're thinking. At least, not yet (see issue 40).
But, depending on your script usage, you may connect them "the hard way" or even better, use only one script. The script on the master spreadsheet can open the other spreadsheet files and do its job "remotely". It's not required that script to be hosted on a spreadsheet to interact with it (read/write on it). You only need a script hosted on the spreadsheet if you're going to use spreadsheet events triggers i.e. on-open, on-edit and on-form-submit.
Maybe you can develop a nice UI for the script on the master sheet and publish it as service. Then only have a link on the copies to access the same UI on a different browser tab. Adding parameters to the link the script UI can even adapt to the particular spreadsheet that is "triggering" it.
Well, that's all I can imagine now. But, unfortunately, there's some use cases that just don't fit this nice "workarounds". For those, one can only star issue 40 (to kind of vote and keep track of updates) and hope it's developed soon.
The solution I put in place in this context was to have a Google Site, where the Master Script is embedded, and where the Spreadsheet is embedded too
Then, the script, refering to a dedicated spreadsheet, looks for the Google Site Page's name, looks in the Master spreadsheet and get the ID of the spreadsheet which is embedded in the Page.
I have solved this problem when using a script which auto generates spreadsheets.
Typically, I will add a sheet to any spreadsheet with a script called "Info." I'll use that to store information that it important to the script. In my script which auto generates more spreadsheets, I keep track of the ID of the created sheet. This way, I can then quickly call up all of the "linked" sheets, and interact with them with using the same script. It might even be worth writing the script in one sheet, and keeping it totally separate from your Master sheet or it's children.
Take a look at this function, it might give you some ideas.
SpreadsheetApp.openById(id)