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!
Related
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.
I am using the Permissions: get endpoint to check if the user has permission the document.
while i am using this endpoint i came across strange behaviour. it was like this as i need to find out if a given user has permission to edit a given document.
1) if the document directly shared edit permission for that user the above endpoint gives me the correct permission object.
2) if the document is shared with the domain privileges (Anyone at who has the link can edit) . In this case every time it gives me a error response.
My view in this case in the google document view even its the domain level share permission or user level share permission the user get the correct set of workflow. But to check these permission levels from the API endpoints does not works as expected.
Is this a known issue? Is their a another way to check the file permission if it shared under the domain level?
Thanks
Given the fact that there is some missing information (i.e. error message, code snippet, screenshots etc.), I'll make an attempt to answer your question here :)
To check for the file permission, it can be achieved in the following ways:
via Drive API
The Permissions.get resource would be ideal for checking the
permission for a user or domain. You may also try using the
Permissions.list, which would lists all file's permissions.
Google Drive UI
Right click on the file, select "Share..."
Click Advanced
With that being said, I noticed in my testing, if the file (doc) is shared under the domain level and you are not performing this under the same domain, both the view and API resource will return an error response. I suggest making sure when you're calling through the API you're using the appropriate domain user. Hope this helps and Good luck!
The Permissions.Get operation can tell if you a file was shared directly to a user, but it can't tell you if a user has access to the file via a group permission, domain permission, or anyone permission.
Using a Permissions.List operation you might be able to tell if the file is shared to anyone or if it's shared to the user's domain (based on, for example, the user's email address).
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'm having a look at Google Drive and we have instances where we will need item level permissions on files. We have groups of people would would have write access to the file. I notice that the API allows you to set permissions on a file with a group id but am unsure how to setup the group in the first place?
Could someone please advise on how to do this?
The other alternative would be to send a permission for each user but this seems like a less ideal workaround.
Just share with a google group which has an email.
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.