Google Apps Script close spreadsheets programmatically - google-apps-script

Google lists a maximum of 50 concurrent users allowed edit permission at once in a shared spreadsheet
https://support.google.com/docs/answer/2494827?hl=en&rd=1
I've got a Google Spreadsheet that will have a large number of potential editors at any moment and am concerned about idle users filling up the 50 cap and blocking edits from fresh logons. There's a lot of interaction with the data that discourages me from using Forms submissions, and there would be a large bound script to the document.
Is there an idle timeout function that can be called through the spreadsheet's bound script that will close the document or set an idle user to view only status? This is in a Google Apps for Business domain.

This is a question that was asked very often 6 years ago on the old Google product forum when I began to work with Google spreadsheets.
Strangely the question disappeared after a while and never came back (until today !)
There are two main reasons for this question to disappear :
Since Google spreadsheets are a representation of a documents hosted on a distant server, we can not interact with what happens in another user browser from a script that runs on this distant server
I suppose this is rarely an issue and that in most case it was mainly a theoretical question that vanished in real use. (but that is really a supposition, I admit...)
As far as I know there is no practical solution to avoid that situation.

Related

Re-authorize hundreds Google scripts indefinitely

I have about 700 Google sheets, running scripts.
For too many years now, I have to re-authorize these scripts indefinitely.
Of course, I searched the net, I simplified my scripts to minimize the number of services called. Recently, I was hoping that the Google Alpha V8 script could have helped me, but no, definitely no. Still no solution.
My hundreds of sheets are opened by the employees of my company, therefore hundreds of scripts linked to these sheets are automatically used thanks to triggers (simple and installable triger)
It seems obvious that there is a limitation on the number of scripts allowed at the same time. This limitation having been visibly reached for years, I have to re-authorize, every day, some scripts. But by doing this, I guess I am revoking so many other scripts. How Google decides to revoke this or that script, I don't know. I guess the least used.
Why this limitation? Is it possible to increase it?
If not, what is the solution?
I add I found this page https://developers.google.com/apps-script/guides/services/authorization , which is talking about OAuth application user limits (at the very bottom of the page) . I wonder if this could help me.
Thank you.
I worked on my topic, reading a lot of english docs... I painly read and slowly understood them. I hope so !
As I could expected, I hit on restrictions, placed by my organization, I imagine. I am unable to create project. See 1
In the same time, and strangely, I own several projects. 2. I don't know why they exist, even if I recognize their names which are those of several of my scripts.
Anyway if I want to publish my script as an Add-on, I have to "link" my script to a "standard GCP project".
As it is impossible to create specific projects, I tried to follow a google procedure, consisting to link my script to an existing project. But as it was expected, it does not work either 3
If someone had a good suggestion, it would be welcome.
Thx.
JM.
Convert your scripts to an add-on. Then these add-ons can be shared across users and spreadsheets, and you can actually reduce the number of places you need to maintain code. You can view the publishing guide here: https://developers.google.com/gsuite/add-ons/how-tos/publishing-editor-addons
A second solution is to create a standard Google Cloud Platform project and change (some/all of) your scripts to use it, rather than their own hidden GCP project. More info about this step: https://developers.google.com/apps-script/guides/cloud-platform-projects
Note that both of these solutions will result in sharing of certain quota limits, which may mean you need to redesign or update how you do things
However, both of these changes provide increased visibility into the errors that your scripts encounter, as you no longer have 700+ places to check for error reports, just a 1 or a handful.

Google URLfetch Quota reached each morning

I am not much of a coder but I have a single spreadsheet in my google docs that interacts with a website's API to pull quantitative data and display it in a helpful way. My problem is I keep reaching my urlfetch quota from google without ever accessing the spreadsheet. As in, the limit is reached upon waking up in the morning, at some point throughout the day the quota resets and I might load the spreadsheet once or twice, then by next morning the quota is reached again.
I can't imagine I am personally reaching the 20k limit. The spreadsheet is literally a dozen cells with numbers, nothing fancy here. My best guess is the problem has something to do with the fact I copied this spreadsheet from another user (who shared it with many, many others). But I was under the impression that the quota was gmail-account specific, so that should not matter?

Architecture of a company-wide Google Apps Scripts

In our company we use Google spreadsheets heavily. I would like to automate some things, for instance every minute I would like to call our bank's API and save all the new transactions into a spreadsheet.
What I'm missing in the official documentation is some major architecture best practices.
First part of the question: Who should be the owner/runner of such user-neutral company-wide script? I would not like to bind it to my personal account. I want it to run seamlessly even after I leave the company some day. Is some artificial technical user needed?
If it makes any difference we plan on moving to team drives in future.
Second part of the question: I would like the scripts to have persistent storages (in the example above - for the record of transactions). I'm considering to be a rule that every script is bound to a spreadsheet which acts as its data store. Is it a good idea?
I generally recommend that clients provide me with an "artificial technical user", as you say, to keep that owner alive and away from my personal account. Which also avoids using up my daily quota especially for regular triggers.
I'd avoid binding the scripts to a GSheet as you'll then get issues with potentially using GitHub or creating add-ons in the future. I generally make all scripts in a separate library (Bruce McPherson did various tests and never found a performance hit) and then link them with a very small script to a script contained in a GSheet if needs be. This allow eases separate development whilst the script is being used live.
GSheets do provide a fair amount of storage (2 million cells) but if you reach that - and the sheets do tend to slow down - take a look at using Firebase for which you get 1GB free and there is a great Firebase library.
There are various general recommendations for Apps Script development. I link a few here.
Happy scripting!

Google App Script limits on number of times doGet can be called

The google script limitations link shows that we can do URL Fetch calls 20,000 / day. Now thats looks quiet ambiguous to me. Inside script, you can use the UrlFetchApp to make get/post requests to external urls. But what if we are calling a deployed google script from external non script client(e.g. web browser/mobile device ).
Does that imply that we can only call the script(with url say abc/exec)20000 times a day(20000=total sum of times the script is called from all client devices) from outside of google app script?
I don't see the relationship between fetching an URL from within a script and running an app from a browser. I never saw any mention of a limit about how many times a webapp could be called but there are probably limits on the total processing time a script can use. The quota dashboard specifies the maximum processing time used by triggers, it does not however specify a limit on processing time by a human user.
If Google does not specify it that means they don't care or that they don't want us to know... in both case the result is the same: we have no way to get the info.
That said, I never encounter any issue with an app being called too often even if I know that some of them are heavily used sometimes.
Was your question purely rhetorical or did you experience some real situation?

urlFetch terms of service and quotas - using Google Docs to monitor website uptime

I've been making improvements to a Google Docs spreadsheet (and the underlying script) that monitors websites for uptime/downtime. You can see a description and copy the spreadsheet here: http://agileadam.com/google-docs-uptime-monitor
I'm a web developer and need to monitor the uptime of 199 (the number will grow) websites. This is an accumulation of many years of development - all sites we control. So, I had a 5 minute time-driven trigger that ran my function, which loops through every URL and checks the HTTP status using urlFetch.
I have two questions:
Is this a violation of the Google Docs TOS?
At 5:57am I got a message: "Exception: Service invoked too many times for one day: urlfetch." According to https://docs.google.com/macros/dashboard the limit is 20,000 for my account. According to my calculations I should have only been around 14,000 uses. Why did it bomb out on me?
I am going to remove many of the domain names that are similar (I suppose I don't NEED to monitor .com and .org for the same site) and I've changed my trigger to run every 15 minutes. This will reduce the number of executions considerably.