According to the following link, shared Google Drives have a membership limit of 600 combined users and groups.
https://support.google.com/a/answer/7338880?hl=en
At my organization, we have a shared drive. We are unfortunately forced to share with users individually rather than create groups due to a conflict between organizational security requirements and our particular use case.
We are automating sharing using the Google Drive API, and we have a growing number of drive members which will eventually approach the 600 number. Is there a way we can find out how many drive members we have so we know if we're in danger of hitting the limit of 600? A user would be considered a member of the drive if at least one folder or piece of content anywhere on the drive had been shared with them. There doesn't seem to be a straightforward way in the Google Drive API to query the number of users that are members of the drive.
Thanks!
I haven't found a way to directly get a drive's number of members but you might be able to make use of drives.list's query and search drives with memberCount having more than 550.
If this gets your target drive, then you should be able to estimate for how long will it get full.
You can also do a repeated query to actually get the exact number of members.
For example:
name contains 'name of your shared drive' and memberCount > 200
if this returns your target drive, then we know it is greater than 200. Proceed with bigger memberCount comparison to get the actual member count
if this doesn't return your target drive, lessen your memberCount and see if it catches your target drive.
repeat until you get a more specific number of memberCount
With these in mind, you can create an algorithm that will loop the call until it matches the actual memberCount. But if it is a hassle for you to do this, then simply querying if your target drive is having greater than 550 members will suffice and should warn you that it is already near reaching the limit.
Note:
You need to use true for useDomainAdminAccess and have administrator privileges for it to work.
Reference:
Search for shared drives
Drives: list
Related
I am using the Google Drive REST Api to get a list a revisions (https://developers.google.com/drive/v2/reference/revisions/list).
I have two problems with this:
The number of revisions is inconsistent. I always get the same last 30 revisions but the total quantity ranges between 70 and 98. Each time I do the call, I get a different number of revisions.
I keep the revision ids for later use (for backup purposes) and when I come back and call GET on the Revisions API (https://developers.google.com/drive/v2/reference/revisions/get), the first few revisions return a 'Revision not found' and some random ones also return the same error.
I can reproduce this behavior in my app but also directly on the API's documentation page.
Is there a way to know which versions are 'permanent' so I don't keep them for later use?
Thanks!
Based on the Manage Revisions page, you're getting "Revision not found" due to the automatic purges made by the service for disk space optimization.
Google Drive automatically purges (or "prunes") revisions in order to optimize disk usage. To prevent this from happening, you can set the boolean flag keepRevisionForever to true to mark revisions that you don't want Drive to purge.
As indicated, you can set the keepRevisionForever flag on a specific revision for it to not be purged.
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.
Referencing this limit: https://script.google.com/dashboard
We have a few forms through our Google Drive, and I use the FormEmailer script (placed in the script editor) to send out a summary notification to two recipients once someone fills it out.
Occasionally, we will have a meeting/gathering where a whole bunch of people will fill out these forms at once.
I did a good amount of research on this but I am getting conflicting information. Some webpages say you can't increase that limit, some say you can (how? We would be willing to pay). It's not a whole lot of extra e-mail, maybe 200 a day instead of the 100 limit.
I see this page but don't see a way to increase it: https://developers.google.com/apps-script/guides/services/quotas
Thanks!
There's no way to increase the limit for Google Apps script.
One possible work around here is to have multiple scripts that perform the same function, and send script1 to some people, and script2 to others or something similar. Alternatively if the two recipients are always the same 2 people, you can consider placing them in a group, and sending the email to the group instead, which counts as sending to only 1 person (Thus doubling your current limit).
I want to make sure that I understand Application-Owned Accounts correctly, because it sounds to good to be true.
I have a shop, and I want to place all my products on my application drive account.
I want to be able to dynamically perform those actions:
Add new products
Delete products
Update products
Enjoy the drive file revisions
Do I get all those for free for all my 1,000,000 users?
What is the catch?
The main drawback I think is that you cannot purchase additional space for service/application accounts. You can have the basic 15GB (at time of writing) but that this cannot be increased.
This is mentioned in the third paragraph on this page
I am using Google drive with my own user account (with expanded storage) via the API to store call recordings: I make the files available via my own website and I control the access so I could have a million users of my app, but use one Drive at the back end.
I'm facing an issue with an application I'm developing using Google Drive.
I have a Google group with some users inside, and I share a collection with this group.
When I try to find this collection using Google Drive API (files().list()), as one of the users of this group, the collection shows up properly.
However, if I add another user to the group (either using API or Google CPanel), and try to find the collection using Google Drive API as this user, the collection doesn't show up, as if the user is not able to see it even though he is in a group allowed to see the collection.
If I manually open once the collection through my browser, then the collection is showing through Drive API.
Is this a normal behaviour ? In my use case I cannot expect from the users to open in their browser each and every collection shared with them in order for the application to work.
Any insight?
I opened a Google Support case about this and apparently this behavior is "expected". Here are some excerpts from my exchange with "Angel" from
Google Enterprise Support (typos corrected and emphasis mine):
After reviewing the stackoverflow question, we need to clarify to you that the behavior shown is expected. When adding a user to a group, this group must be added again for any files that it has been shared with.
and
All information previously provided is from internal documentation for Drive UI; however the functionality is the same for SDK, therefore, group must be deleted and added back to the list of users that have access to files/folders after adding a new member.
So, there you have it. Not sure if #Burcu will ever come back and confirm.
<EDIT> It gets worse. According to this Google document, groups with more than 200 members will never see files shared with them, even if you delete and add the group back. </EDIT>
Useless post-answer rant follows:
This behavior, even if it is "expected" by Google, does not seem to be properly documented, and it is neither expected nor usable by clients of the service. How are we supposed to know when a user has been added to a group that has items shared with it? Are we supposed to constantly monitor group memberships as well as maintain a list of all things shared with the group and then *re*share them with the group when the membership changes, just to get consistent behavior? It makes me wonder why Google doesn't already do this on the back end; it can't be that expensive to register a list of callbacks with a group that are triggered upon membership changes. And the requirement that we actually unshare is even more bizarre, since it necessitates a short period of time during which nobody in the group can access the resource.