Is it possible to have compound permissions on files? For example, I'd like User A to have writer access until a set date, then after that date they can only comment (or view) the file. Right now as I'm testing on my personal files, the API explorer doesn't show all the permissions I have set.
Directly though the API you can set the roll and type of access each user has your application would have to remove it after said date.
You could try reading the documentation: Permissions: create
Have a look on the expirationTime field in the permission resource
https://developers.google.com/drive/v3/reference/permissions
You can create a permission, that will expire at the defined moment.
So for your task, you can create two permissions one for reading and commenting without expiration time, and another for writing with expiration time.
Related
Using the app script properties service I can allow users to store some settings information. I understand that these are stored for a given user for a given script. As the admin is there anyway for me to review all the users properties?
Also does anyone know if you are allowing the script to run as you (the publisher) does the user properties store as the user accessing the script. I know that the session data is for the actual user and not the publishing user(even when running as the publishing user).
Thanks
I'd like to suggest storing the user properties in Firebase. This will give you full access to them as needed, and they load really fast for the user. My two go to docs for this are this one to get the library and this one to as for details. If this is not possible, an alternative could be to append a row to a google sheet each time the user updates their users properties. I use both of these approaches for also tracking detailed app usages.
I have a GSuite with user groups, every group is one department in the organisation. I got the following permissions now:
Every department can edit his own folder
Every department can view folders of the other departments
Only I want that every department who can view something, also can comment on GDoc files and Spreadsheet files. I know I can change this on every file indiviually, but our Drive has over 1000 GDoc files. I'm not going by every old (and new) file to change this permission everytime.
I tried to solve this with a script and tried
file.addCommenter(email); -> Invalid argument: permission.value
file.setSharing(DriveApp.Access.PRIVATE, DriveApp.Permission.COMMENT) -> No error, but also no result.
Does someone know a solution for this?
file.addCommenter(email); -> Invalid argument: permission.value
That's a tricky one. There is an open issue #4231 since July 2014 (!) about this. I have not personally encountered this, but apparently it is an issue, though may be a rare one. Is it a specific file type that this fails on? I have just tested file.addCommenter(email) on all Google file types, and it worked without an issue for me.
Is the account your script is executing under the OWNER of these files, or only has 'EDIT' access to them? Has the option 'Prevent editors from changing access and adding new people' been enabled for these files? These are some things I would start checking to pinpoint the cause of the issue.
If all else fails, I suggest you contact Google Support rep with this - there should be a link for this in your GSuite Admin Control Panel.
file.setSharing(DriveApp.Access.PRIVATE, DriveApp.Permission.COMMENT)
-> No error, but also no result.
I do not think this will do what you expect it to. setSharing() method sets the sharing properties of the file besides any individual users who have been explicitly given access. Basically, setSharing() method will not change the sharing access of users who have already been explicitly granted some level of access to the file.
The way you could potentially use it, is to grant COMMENT access to the file to any user in your domain using file.setSharing(DriveApp.Access.DOMAIN_WITH_LINK, DriveApp.Permission.COMMENT), provided you are GSuite for Business or EDU user.
Hope this helps!
I've written a test suite for my google drive api library and am witnessing some non-deterministic behavior. In the simplest case, I can insert a permission on a file, then immediately get a list of permissions on the file and I don't see the newly inserted permission.
I'm chalking this up to eventual consistency being eventual, but it would be nice to know if this is actually the case; the documentation makes no mention of consistency delays.
I can't see this documented anywhere but there is a simple experiment you can do.
Adding and removing permissions is an asynchronous and queued task in my opinion and eventual consistency is my observation too. You can confirm this with a GSuite for Business account by conducting a test as follows:
In the Drive UI, upload a folder tree structure with a root folder, 3 or 4 levels of sub-folders and 300 to 500 files. You may get away with fewer but this is how many I used.
In the Drive UI, share the root of those folders with another user on your domain.
In Admin Console > Reports > Audit > Drive, add Filters as follows:
Event name: User Sharing Permissions Change
User name: the email of the user you added in step 2.
Owner: your email
Date and time range:
From: add yesterday's date
To: add today's date and 23:59 as time
Press search. You should see hundreds of events - one for every file and folder you added in step 1. Each event shows the exact time stamp of the permission being added.
As you should see, the permissions are not added instantly. It can take many minutes/hours depending on the numbers involved and (I assume) indeterminate work going on in the Google cloud.
It is indeed. If you think about Google's infrastructure, it's all about read performance and data integrity through massive distribution. The inevitable consequence of that is that write performance is relatively poor and asynchronous.
After copying a file with a service account, I add a permission of "writer" to a user in the same domain to the copied file and redirect the user to the file's resource "alternateLink".
since a few days ago the user gets the following message "You need permission"
This happens consistently.
refreshing the page grants access to the file.
Is there any way to insure the file is ready for editing by the user before redirecting them? I tried to get the file again with the user's authorization and check it is editable, but that only results in false positives.
Edit: the problem is no longer consistent, I will try suggested answers as if and when it returns.
Your Drive account might take some time to process the calls from the API. With that said, you can rely on the following methods to verify the user's permissions:
You can rely on the "list" function of Drive API, for the Permissions resource.
Within the response from the API, there is the "Items" property, which in turn will show the detailed information about the users for a particular file.
You can find more information in the following reference: https://developers.google.com/drive/v2/reference/permissions/list
If you have access to the user's account, then you could rely on the "Files" resource, using the "get" method for a particular file.
Reference: https://developers.google.com/drive/v2/reference/files/get
One solution that i implemented is setting some safe amount of delay , say 30 seconds using timertask
I am not sure if I am experiencing bugs or if I am doing something wrong. I am developing an app that allows users to create and share a folder on their Google Drive so they can collaborate on the contents of the folder. The folder is created at the root of the user's Google Drive and initially contains a couple of files and one sub-folder with more files.
The first issue is that after inserting a new permission on the main folder, the permission will usually propagate down to all the files and sub-folders, but sometimes it fails to insert the permission on one of the files in the sub directory. Is this feature of propagating permissions to sub-directories something that is officially supported or am i suppose to insert a permission into all the files separately?
The second issue I am experiencing involves the use of the File's userPermission property to check if the role of the current user has changed. It seems that the userPermission property sometimes contains the permission of a recent user and not the current user. The feature I am trying to implement is the ability for a user with whom a folder was shared to check periodically if their permission role has changed. For example has the users permission role changed from "reader" to "writer" or vice-versa. This usually works by listing the folder with the fileId and checking the role property of the userPermission property of the file. However if I am testing this feature with both the user who shares and the user with whom it is shared working within the same client, the get file result will often list the userPermission as the last one to access the file and not the current user. I have tested if this was because I was using the wrong oauth information in the request header but I have ruled this possibility out, the oauth headers are correct for each separate call to get file. I added a test call to about witch lists the users permissionId, just before a call to get file to confirm who the authorized user is. Sill the userPermission with the "me" name appears for the wrong user.
The workaround I have found is to use list files which returns the file in the list with the correct userPermission.
In the reference located at https://developers.google.com/drive/v2/reference/files#resource for the description of the userPermission property is "The permissions for the authenticated user on this file."
I am wrong to interpret this to mean the userPermission will always show the role of the current user? And if it is showing the wrong permission, what could be the cause??
userPermission and me represents the current authenticated user, if it's showing the wrong permission you're authenticating the user with the wrong token.
the permission will usually propagate down to all the files and sub-folders
This case may not be true for sub folders and files with their own explicit permissions.
With regard to the first problem, which was that after sharing a folder, only one of its contents would consistently not get shared, I have discovered the cause. The file that was not getting shared is actually a Fusion Tables file and in my script, immediately after inserting the permission, a call is made to insert a new row into the Fusion table file which seems to prevent the permission from being added to that file at that time, or ever. So the workaround I found is to wait a couple of seconds after making the insert permission call, then check that the permission is already in place using a list permission call before calling the Fusion Tables query.
Now with regard to the second problem, this is probably a bug of some sort since I confirmed that I am using the correct oauth token, and by the fact that the workaround I have found works, which is to use a call to list file instead of get file. The only difference is that the file name or other query parameter is required to make the call in addition to the file id. In my case the file object returned with the list file will always contain the correct values in the userPermission field whereas with get file, the userPermission will sometimes contain information for an other user.