Is it possible give a Google App Script permission to create files in a user's Google Drive, and then only have edit/delete access to those files, without having write access to any other files?
From what I can understand, the permission I need for this is drive.file under dependencies.enabledAdvancedServices[].serviceId, which is available in Google Drive API v3, but Google App Scripts only supports v2 (at least, as far as I can tell in the "Advanced Google Services" dialog).
Is there a way to get drive.file in GAS that I'm missing? Or has Google announced any plans to bring v3 into GAS? Or another way to restrict my script to only having write access on files it creates?
Related
I have a Google Apps Script that I am currently using to successfully open a Google Sheets spreadsheet (read-only shared with my account) and perform some reading functions.
I received another spreadsheet that I would like to run similar processes on.
If I try:
SpreadsheetApp.openById("_______") (which works on the other sheet), I get Exception: Service Spreadsheets failed while accessing document with id _____" with this sheet. This spreadsheet is actually an xlsx on Google Drive (but appears it can still open in Google sheets) rather than a native Google sheet so I figured maybe that was the issue...?
So now I'm trying to instead access it as a Google Drive file using DriveApp.getFileById("____"). However now I get an authorization request to allow my script to access Google Drive. When I authorize it, I get:
This app is blocked
This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access.
I haven't found a way to fix this. I'm on a private Google account, not using a company's Apps.
Any ideas?
Found a solution to the permission issue.
To work with Apps Script, I've modified this from #alper's solution which sources #tellowkrinkle's comment.
Do the following:
Go to https://console.developers.google.com and create a new project for yourself
Search for the Google Drive API in the search box at the top, and turn it on
Click OAuth consent screen on the left and set it up.
Assuming your account isn't part of an organization, you'll have to say your app is for external users and in testing
In the required scopes section, add .../auth/docs and .../auth/drive (I'm not sure which needed, it's probably only one of those). This will probably not be available if you didn't complete (2)
Add the accounts you want to use with your copy of gdrive as testers of your app. Only these accounts will be able to use your copy of gdrive, so everyone will have to compile their own (unless someone goes and gets theirs reviewed by Google). I only added my own account because I am the only one using my App Script which uses my Drive.
Click the 3 dots on the top right and select "Project settings". Make note of the "Project number".
Go to your Apps Script. Go to Resources > Cloud Platform project. Insert the project number from (4).
Next time you try to run your Apps Script, you'll be asked to Authorize but this time you'll have the chance to actually do it successfully.
I'm working on an Forms add-on which would allow you to export survey response data and/or save it to user's Drive. Is there no way to do this other than allowing full Drive access through the most extensive scope?
And about publishing editor add-on, how does one go about with it? I'm unable to get it to G-Suite marketplace, and the original unlisted version was on Chrome Webstore. (which is now unavailable)
I tried to test it with "Integrate With Google" via the G-Suite Marketplace API, but nothing shows up when testing. I don't know why, since the add-on works as expected via "Test as extension" from Google Apps Script editor. And the "waiting for review" has been taking ages. Is there any way to know the status of it?
EDIT: It seems like only Drive API can be used with custom scope (after enabling it), but DriveApp always requires full-access scope. And the functions that fetch files from Drive ONLY give out those that the script has access to (created or opened with) if you're using drive.file scope.
...the publishing part is still a mess though.
Regarding scopes and using Drive through Apps Script, there is two things that are needed to know.
1) DriveApp class that is readily provided in Apps Script, always requires full read-write access to user's Drive. This apparently can't be changed.
2) Drive API (v2) under "Advanced Google Services" allows usage of all available Drive scopes. This, however, needs to be enabled separately.
Another thing: drive.file scope allows you to only access files and folders in user's Drive that have been opened or created with specific script. This includes queries, so you only get what you can access. No need to check permissions separately.
If I open the shareable link I have got for a file from Google Drive in the browser, I always get either to the Drive's internal preview program or to a download page (See below).
I would like to know whether there is a programmatic way to launch a specific drive-connected application (with confirmed access permissions) to open a file for which I have the link (and thus, the ID as well).
I don't want to do this through the drive's interface, but rather within my program. Let's say I want to let the users browse their files and open them in the browser with their default app as they have defined it on their drive (and let's say I already know that app).
To make it clear, I just want to achieve what Google Drive's interface does in the browser: You click a file, and it opens in a new tab in your default app.
In my opinion, this is possible with the use of Advanced Drive Service and Drive Service.
Advanced Drive Service
The advanced Drive service allows you to use the Google Drive web API in Apps Script. Much like Apps Script's built-in Drive service, this API allows scripts to create, find, and modify files and folders in Google Drive. In most cases, the built-in service is easier to use, but this advanced service provides a few extra features, including access to custom file properties as well as revisions for files and folders.
and for the Drive Service, you can use getUrl() method to get the URL that can be used to open the File in a Google App like Drive or Docs.
This service allows scripts to create, find, and modify files and folders in Google Drive.
Detailed information and sample codes regarding these services can be found in the documentations.
Is it possible to use Google apps scripts deployed as a web app to integrate into the Google Drive UI?
i.e. opening files similar to: https://developers.google.com/drive/about-sdk#create_and_open_files_directly_from_the_drive_ui
But using Google scripts: https://developers.google.com/apps-script/
Scripts do have access to a drive api, but I'm unsure if they have the capability to integrate into the Drive UI?
Yes. You can create a script, deploy it as a web app and call it from the Drive UI as shown in the link you provide. Your script is passed parameter from the Drive UI (including for example, the folder currently selected) and you work from there... I use this mechanism to work with a folder structure representing client activity. Selecting a client folder, I can choose to open with my script or the usual Drive options. My script checks the parameters passed by drive and responds with an appropriate user interface for the next step.
I've noticed that some google drive apps fire POST request to https://docs.google.com/picker/drivepreopen?hostId=myhost upon file selection in picker dialog. Does anybody know what it does?
I need to be able to access my google docs files from my google drive app and I'm aware of the fact that drive apps can access only files it created or opened via context menu in google drive. As the name "drivepreopen" suggests maybe it allows you to programmatically invoke "open with"?
The Picker is how your app should be given access to a file and it can be used to display a list of the currently authenticated user's Drive files, as explained at https://developers.google.com/drive/integrate-open#open_files_using_the_google_picker.