I recently created a Google script for my documents but I'd like to know how to authorize all my documents to execute this one, not only the document that I used to develop the script...
First, Is that possible without passing on the store?
I have great news for you! Google says they're working on that!
But also bad news. They've been working on it for four years now, which really means they're not working on it.
See Issue 489, star it and wait for the announcement of project completion. He he!
The topic of sharing scripts among multiple documents has been covered before:
https://stackoverflow.com/questions/5334751/how-do-i-share-a-script-i-wrote-with-my-co-workers-on-the-same-google-apps-accou?rq=1
Libraries.
How to share one Google Apps script between few documents?
Libraries.
What happened to the "Publish to Gallery" option in Google Apps Script?
The gallery was retired.
Google Apps Script add code to copy of a document
Can't do it.
Option 1: As those previous answers suggested (and I'm sure there are more), turn your script into a library, then in every document you want to use it you "just" need to add a script that includes the library, and functions that call the library functions.
Option 2: Any stand-alone script can be "tested as an add-on", which allows you to associate a script with any document. Unfortunately, just one document at a time.
Option 3: (Your own suggestion.) You are able to publish through the store, but limit the visibility just to yourself (any account), people with the link (any account) or your organization (domain accounts). If you're using a consumer account, you'll have to pay $5 to register as a developer for this privilege.
I'm uncertain about whether you'd need to wait for a review cycle, or if your add-on would go live immediately, or if you'd be able to skip providing help documentation, support web site, etc. - maybe someone else can weigh in on that via comment, and / or update this answer with details.
The advantage to this would be the ability to have the script in any of your documents, without adding scripts to them.
Consumer account add-on visibility options:
Corporate domain account:
Related
Am I correct that there is NO direct replacement for this process on marketplace:
publish unlisted on chrome add-on store
directly share the link with others who can use the script
In particular, the mechanisms allowed me to use a script that I write across all my google dsocs.
With the move to marketplace, is there any way in which I can do this? I.e., write a script (container-bound or otherwise) and have access to it from ALL my google docs?
This is not about privacy: I am super-happy for the script to be shared with others or be public, but the review process has already turned down the script as unfinished. However, the script does what I need it to do... so I'd like to be able to use it across my google drive primarily... however, with the new google marketplace that doesn't seem to be possible.
One way may be via Google Suite domains. That seems to allow for internal publication. However, I've done that, and so far not received an acknowledgement or notification (while the GSuite page says 'under review'). My understanding was that internal scripts weren't subject to review.
Would anybody be able to comment on this and confirm, clarify or refute this understanding?
The move to Marketplace has certainly caused a lot of confusion! Trying to find all the tick-boxes can be difficult.
The two main places to look are the OAuth Consent Screen, where you need to make sure it is Internal (you have to have a GSuite account for that):
And the Marketplace SDK under Configuration check it is set to Private (although note that if it has transferred from the Chrome store it may already be set to Public, and this can't be changed). And under Publish it is set to unlisted.
This "unlisted" setting may be the crucial one for you as even if it is "Public" it won't be in the Marketplace, but will only be available via a link. But if it is "Public" I don't think you can make updates without going through the verification process. But if you don't go through the verification it should still be available.
Hope this helps, happy to answer any other questions.
Andrew
I read this:
https://developers.google.com/apps-script/guide_libraries
and
Distributing Google Apps Scripts for Sheets in your company network
I have a simple udf for google sheets that I'd like to share with a couple other people. Whenever I need it for a new sheet, I just copy and paste the code into the script editor and run a smaller function in debug mode. Then the computer asks if I give permission to my little script to run and I say yes. If other people want to use my udf, I can't expect them to do the same thing because they're not programmers. Well, I'm not either, but I try. Anyway, is there a way to share it without publishing an add-on or that domain admin sequence of events or anything involving long authentication strings or oauth2.0. all of this is too overwhelming for me as I'm not a real programmer.
Also, is there a way to share the udf without sharing the code, because the code is constructed embarassingly and more importantly, there is some info I'm not sure I'm allowed to share.
Speaking of things I'm not sure of, I'm not sure if this counts as an app for work because we use the app for work, but it seems like your company has to pay for something to be considered an app for work even though these apps seem like they're for free.
Apparently there is an open issue regarding Protect Google App Script. It would be best to follow this ticket to be update on how you would be able to protect your apps script code. Migrating your code to an external script and make it as a library would protect your code from editing but not from viewing.
Creating an app for your company may not be considered as an app for work. According to this document:
Google Apps for Work adds business-specific features such as custom email addresses at your domain (#yourcompany.com), at least 30 GB of storage for documents and email, and 24/7 phone and email support.
I'm working with a few schools to develop a series of interactive textbooks for students. The textbooks need to have randomly generated exercises, for which I've already developed a prototype.
It's also required that the app is managed entirely through Google Drive (eg, I can't use WordPress or even Google Sites), although I can create my own Apps - so long as those can be installed and accessed through Drive.
What I'd like to do is:
Allow authors to create randomly generated worksheets using Google Forms, similar to how they can with my current generator
Allow authors to click on a menu item in Google Docs that embeds a widget/iFrame inside a Doc
Embed JSX Graphs into a Doc
Log students answers into a Spreadsheet
"Pretty-fy" spreadsheet into a nicer display in an instructors page - either in spreadsheet, doc, or custom Google App
Everything must work off of Google Drive
My questions are:
Is this something that can be achieved purely through Google App Scripts?
Would someone viewing the Docs be able to see the embedded widgets without my App Scripts installed (if this is even how it works).
Can I extend Google Apps (when viewed by a visitor) to show a sidebar with ToC
Can cross-document TOC be built, where a TOC is generated from the Headers of all docs in a folder?
Would it be easier to create a Browser Extension that can search for certain strings (or even better, a placeholder image with "please install extension") in the app and replace them with the interactive widgets?
Browser Extension
Aside from extending Google Apps, I could also create a browser extension that students install that does #2...this would be fairly easy. Of course, "Install" is a scary word for parents, so preferably a solution that doesn't require students to install anything.
I guess, really, my direct question is this: Can Google App Scripts alone extend Drive Apps to create interactive textbooks for students and teacher planners.
As commented by Mogsdad, your question is indeed overly broad. But I'll attempt to answer it.
From the list you things you'd like, only point 3 may be problematic. You'd have to test if JSX Graphs works well with Apps Script Html Services. I'm afraid it won't. But you have other Chart solutions on Apps Script.
From your list of questions:
I don't think so, unless you make some compromises on your requirements.
No, only scripts installed on the document/form/spreadsheet itself can embed widgets on it.
Not with Apps Script, to run/interact with scripts the user must be a collaborator, not a visitor (meaning he must have edit rights on the file). Maybe with a browser extension.
Yes. But if there's "too many" files to be processed, you're likely going to hit some Apps Script quotas that will make your life difficult.
I didn't really understood this question. But browser extensions can surely do more than scripts, but they will require installation on each browser for all your users.
I think this is the same as my question: http://code.google.com/p/google-apps-script-issues/issues/detail?id=852
But just to be clear: Google apps scripts won't run on a Google Site without a google/gmail user being signed in?
...are there other google products where GAS can be deployed for non-google accounts?
Thanks,
Nathan
False. You can embed an Apps Script in a Google Site using Insert > Script Gadget. Just be sure that the publishing setting is set to "Anyone, even anonymous".
You've got two different levels of user identity at work here, if not three or more. I will try to pull them apart for you in a clear way.
Google Sites can work for users of Google and non users. It depends entirely on the sharing settings for that site. If you share it with the world, it will be shared and indexed by search engines. If you share with anyone with link, search engines won't index it but no user will have to sign in to use the site.
What you are embedding in a Google site may have it's own user identity issues. The easiest way to manage these is to go into 'Publish' menu, and 'deploy as Webapp'. You will then see a menu that asks which account the script should be run under, essentially you or the user. And then which people to allow access, which you would select 'Anyone, even anonymous'.
This will run that app as your account, but allow anyone to call it. Works great for allowing the public access to a form created in GAS.
Now the other problems. It may be possible for you to have code in your GAS that specifically calls for a user. In that case all of the prior settings don't matter. When the script looks for a user and finds nothing valid it will error. These call are pretty obvious though and are more rarely used. (At least in my experience.)
But, in short, yes! You can certainly embed GAS into Google sites to be called by anonymous users.
Example of mine: https://sites.google.com/site/greenmountainretreat/sign-up
The issue you are referring to is about inserting i-frame gadgets into non-Google sites... please don't confuse things... and read the issue report thoroughly.
If you want another example...
I had several questions regarding the usability of a "G Suite/Google Apps API." I would like to integrate some sort of document/spreadsheet/presentation management directly into an application I am building.
This service would have to have the ability to import and export to DOC/XLS/PPT/PDF etc..., so something like Feng Office (if you have ever heard of it), wouldn't suit this need.
For this purpose, I'm looking into such a thing exists. Before I would begin this endeavor, I was wondering:
Do the G Suite/Google Apps productivity tools allow documents/spreadsheets/presentations to be created, read, updated, and deleted all from a third-party application?
Would potential users have to have a Google account in order to use document/spreadsheet/presentation editor?
Could multiple users on my application access files under one Google account, if an account is needed at all?
Last, is it possible to skip a Google account, and let Google docs directly access and save documents on my local server?
Sorry for the crash list of questions, but if there is anyone who could help with these, it would be much appreciated.
spryno724
Yes.
Not necessarily, you can have your backend script sign in as you, or even better, an admin account set-up specifically for your app.
Yes, see #2.
I don't think so.
(Feb 2017) The executive summary is that you can do what you envision, either by using G Suite (formerly Google Apps) APIs or Google Apps Script. TL;DR below in response to your "mini-questions".
Yes; you can do it with...
Individual app REST APIs, i.e., Sheets API, Slides API, etc., or just the Google Drive API.
Keep in mind that the Drive API is used for file-oriented functionality (create, delete, import/export, etc.) while the individual APIs are for document-oriented functionality (editing, formatting, etc.)
To learn about using the REST APIs, see the first few videos in this playlist, specifically videos 2, 3, and 4 to start with
An alternative that's more like using "services" vs. APIs but that can also programmatically CRUD G Suite documents is Google Apps Script, server-side JavaScript apps that are hosted at and run in Google's cloud. If interested, I created an Apps Script intro video for you.
FYI, videos 5, 8, 22, and 24 from the playlist above are for Apps Script if you want to pursue that
Note that neither Google Docs nor Google Forms currently have REST APIs, but you can programmatically access them from Apps Script.
Yes, users need to have a Google account but they don't have to create a Gmail address. See this page on creating Google accounts without Gmail. (If they do want to create a Gmail address, then they can use this page instead.)
Yes, you would use the Drive API to set the sharing permissions with your users. See this page on Permissions and this one on Sharing for more info.
Not really; you need at least one Google account in order to access Google Drive where the files would be stored. You can, however, manage the files on your own, then import to Drive and export from Drive to allow your users to edit on your servers then push them back to Drive. For more info on import/export formats/MIMEtypes, see my answer to another SO question.