We built a purchase order system in Google Docs using Google App Script. The basic structure is a Google Web App, in which the user selects a few options, that app then clones Google Sheet templates to produce a Purchase Order (PO) document. The template includes a trigger to load an app script library we wrote, which is a set of custom menu options to control the PO workflow. Everything works well, except that every time a new PO is created (again, cloning from a template sheet), the users are required to re-authorize the app script. This adds several additional steps per person that are totally redundant. This is likely because the script is bound to the document, but not sure how to get around this since it creates custom menus and needs to be loaded on open.
Any way to have the user authorize the script once for all copies of the template?
Related
I'm new to apps scripting and have created a web app which is container bound to a spreadsheet.
The app provides an html form for patients to record blood pressure readings as they take them during the day. A query string on the web app url identifies the individual patient and puts their readings on a sheet, unique to them, as they submit them. The script is deployed as a web app (Publish -> Deploy as web app) and in my development account it works well.
Now I want to share the script with a few other accounts not in my domain, so that they can use it independently with their own patients, with their own web app url, with readings going onto their own spreadsheet and for me to be able to maintain the code centrally.
Researching this I see official addons are now provided through the Gsuite Marketplace. It appears my choices for 'sharing' are these:
create an officially reviewed addon and put it in the Gsuite marketplace but creating an addon for the world is not what I want to do (atm anyway!)
create a private addon for inside one domain but I want to share it with several domains
there appears to be a system for testing the script as an add-on, without publishing it and for sharing the testing but this is mentioned in the Gsuite addon docs but not mentioned in the Editor addon docs and anyway it's for testing.
share the spreadsheet in my account but then all readings end up on my spreadsheet
share the spreadsheet and code to other accounts so they can make a copy but then I can't maintain the code centrally
Can anyone suggest the best way to share this web app script so other accounts not inside my domain can use it independently but ideally so I can maintain the code centrally? Thank you.
I see two solutions here. One is to add a small amount of "user management" code to your tool. For example, include some query parameters on your base url such as email and authorization key. Set up a user-management spreadsheet with your list of users, mapping their email to a secret randomly generated authorization key, and their data spreadsheet ID.
When the script is accessed with a valid email/authorization_key combination, it then opens the relevant sheet and does its thing.
In this scenario, you would either need to have access to all the relevant spreadsheets (if the code is executing "as you"), or you would need to figure out a standardised file layout or approach that let your script locate the right files on each users drive (if the code is executing "as the user accessing the web app").
Another solution here is to use an Apps Script Library. Using a library would allow you to keep the bulk of the code in the library, while having lightweight "wrapper" code bound to each of the other users spreadsheets. This wrapper code would simply pass doGet/doPost, and any other function requests back to your library.
For example:
function doGet(e){
return YourLibrary.doGet(e);
}
function doPost(e){
return YourLibrary.doPost(e);
}
function aCallback(a,b,c){
return YourLibrary.aCallback(a,b,c);
}
In the library scenario, each sheet and script can be private to the individual users, you would just need to walk them through the initial setup/deployment, and occasionally have them bump the library version and re-publish the web-app in their copies.
I am building a Google Apps Script application for Google Sheets that I would like to deploy as an add-on in the Google GSuite Marketplace. My application has three components:
An embedded custom menu and set of dialog boxes within Google Sheets that allow one set of app users ("User Group 1") to manipulate spreadsheet data
A web app that provides another set of users ("User Group 2") with mobile device access to different set of functionality that involves spreadsheet data
Template sheets (ideally, hidden from the user) that the app can use to generate additional sheets programmatically as needed.
I would like to deploy all components as part of a single add-on. I'd like components 1 and 2 to be bound to the same spreadsheet. In fact, I'd like someone in "User Group 1" to be able to click a button to get the URL for the web app. This would require the ability to peform functions on the "Publish" menu through Apps Script code.
My reading of the documentation on add-ons makes no mention of the ability to deploy an add on that includes (a) a UI embedded within Google Sheets, (b) an associated web app that operates on the same user spreadsheet, and (c) template (hidden) sheets. Does anyone have any experience with this, or suggestions on how to proceed?
At present, the only solution I see is to deploy two separate apps (components 1 and 2), but then the web app would not be bound to a specific spreadsheet and hence would need to use a different API. As for accessing template sheets, I think it's possible to access an external sheet through a URL, but I do not think it's possible for an add-on to include template sheets.
Number 1
Add-on User interface
Add-ons can create menu items and open dialogs or sidebars. For custom interfaces, the HTML service offers client-side HTML, CSS, and JS with a few limitations: notably, our security sandbox doesn't work with many JS libraries.
Custom sidebars
A sidebar can display an HTML service user interface inside a Google Docs, Forms, or Sheets editor.
Number 2
I am not completely sure that I understand your deployment question - however
Both standalone scripts and scripts bound to G Suite applications can be turned into web apps, so long as they meet the requirements below.
I was able to deploy both an add-on and a web app from a single Standalone script
Number 3
Use the copyTo(Spreadsheet) to copy a sheet from a different spreadsheet to the one you are working on and change the name with setName().
Or you can make a template sheet in the same spreadsheet and use hideSheet()
I wrote a script in GSheets we use at my work that uses custom menus. Because everyone is set to "Can view" on the template, they are forced to make a copy as to not affect the template.
The downside of that is each spreadsheet will require authorization to run every single time the form is sent in and the menus need to be used which makes the process more cumbersome. Is there a way I can provide authorization to run the code, whether it be through an onOpen trigger or some other means?
The code includes moving sheets into folders, extracting data to a central spreadsheet, and sending emails. The email does not need to come from the user, it can be sent as a no-reply/anonymous user if that helps.
I have a document container-bound script, that I would like to publish, I would like to make it available to people in my google apps organization. I know the script gallery is only available to spreadsheet apps, so how do I publish it. Or, more specifically, currently the script is bound to one document, how do I make it run on all documents? My user base is fairly small, about 300 people, and I can have each one of them install it if need be.
Thanks,
Ari
There are limited options for distributing container bound scripts. When a document with a container bound script is copied, the script is also copied. So if the 300 people in your organisation copied the document they would also have a copy of that script. The issues with this techniques is that the script is only attached to that particular document and creating a new document, rather than taking another copy of the template, or opening an existing document will not include your script functionality. The other issue the script in the copies of your template becomes orphaned and you cannot push updated versions. Using Managed Libraries addresses this to a degree but the end user still needs to select the newer version of the script in the script editor.
A way to mass deploy your script in your organisation is using Google Apps Script authored Add-ons. Add-ons are installed by users and become available to every document they work on. The script behind add-ons can also easily be upgraded without any user intervention. One issue with this approach is all add-on's need to be approved by Google. This introduces a risk that Google will not publish your script as an add-on. Whilst there is a public store of add-ons after your project is approved by Google there are visibility options to restrict access and prevent there general visibility. As per add-on publication step #12:
In the "Visibility options" section, select which users will be able
to find your add-on — usually either all users or only users with an
account in your Google Apps domain.
Hopefully when add-ons leave developer preview Google Apps domains will have more control over publication and visibility (I've opened a feature request for this)
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......