I'm searching for this like crazy and I just can't find a answer.
Imagine this. I have a "master" account. Using the Docs API I will grant access to users to some documents. But I need my addon enabled in every file. The users that will have access to the documents are not under my organization G Suite or anything. They are random gmail users.
Is there any way to do it? (besides of doing it manually) I couldn't find it in the documentation.
It's not possible to disable an add-on, but an alternate solution is to create a service model inside your add-on. Maintain a DB of users that have installed your add-on, using this you can develop a logic which user is allowed to use an add-on.
This is by far the best solution I can think of.
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 got a little bit stuck right now at deploying my Google Script App.
I've developed a Google Script App, which is embedded directly into
Google Drive (Spreadsheet). It's not a Web App, it's a user interface
in Google Spreadsheet (sorry, but i have to be clear).
That Script is just for one person in another company.
How can i deploy my script to her?
I've read about Domain-Wide-Installation and publishing an App to the marketplace, but i want to deploy it just for her and no one else.
How can i achieve that?
Thanks
Best regards
A big thanks to Sandy Good.
"You can publish an Add-on as "unlisted", which means that it can not be seen in the Chrome Store, and does not need to go through the approval process. When an add-on is installed, it has the authority to check the users email address. So, you could set it up so that it could only be installed by this person. An Add-on will keep the code from being accessible to anyone. Although you might want to also use private functions. I don't know if there is a better way for the Domain Administrator in a paid account to do what you want. I don't know anything about that." - Sandy Good.
That was exactly what i was looking for. Thanks
An add-on can also published for testers. Those testers must be part of a google group. Maintaining a group is easier.
When I deploy my GAS project as a web app, I choose to execute the application as the user accessing it. The option for 'Who has access to the app' I can choose just myself, or everyone in my domain. This I understand.
However, in our Google Apps environment - the domain I belong to is one of many 'sub-domains' under one 'tld' domain to which I have an admin account. I don't have privileges to go full exploring in the control panel to see the exact organization, but I know that I can share docs to everyone in all domains via my Drive. How can I get my script to operate in a similar manner?
There are a couple of good resources on this topic.
Stackoverflow question which links to this
Google support answer
With Google Drive, "You cannot restrict sharing to the users in a single domain". I haven't found an answer to this, but this was the closest that I could find. It seems that you will just have to test if "Anyone in my domain" actually means "Anyone in my organization." If you can test this and report back, I will update this answer.
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.