I work in an areas with about ~200 school based collaborators and we all have access to the same Google domain. Using Google AppScript (that pulls from a Google Spreadsheet generated by a python cron job), I am programmatically creating a pre-conference form that is custom-developed to each of the schools, yielding me about 200 forms. This all works fine.
I need to attach a trigger on the submission of each of these forms. I have it written and tested the function. All works fine.
The problem is I cannot propagate the submission logic to all of the forms because of the 20 triggers / user / script quota limit. Each of these forms is only going to have 1 response, and it would make sense to me that I should be able to have 1 trigger / form (I will definitely be under the 6 hrs/day processing limit for triggers).
So, this issue is occurring because the AppScript trigger limit is in terms of the code that is being called with the trigger and not the Form that is triggering it. Is there another way to set up the Google services to avoid this quota? I can be flexible and I've already created a batch service to create the forms without violating the 6 minute maximum execution time, but it seems like any attempt to have one script creating more than 20 forms with 1 trigger will lead to failure.
Related
Have been searching for a clear explanation of the quota rule for triggers, but in vain. Can anyone explain if this below will work?
I am creating 50 scripts for 50 files (the code inside each script only differs by each of 50 files id). Each script will have an installable trigger onOpen, where a function referring to one single master file, will be executed. I read the quota 20 triggers / per user per script and cannot make a conclusion regarding my situation based on this rule...( Thanks, all in any case!
I do believe here in this article where you have read these quota limits presented.
Triggers 20 / user / script 20 / user / script
20 triggers can be added by a single user on an App Script file, and App Script is a collaborative development tool, multiple users can contribute/collaborate on an App Script project, which means a single App Script project can contain 20> triggers if multiple users are working on the same project/file.
Relating to the setup you have explained, since you'll be only adding an onOpen() trigger, technically this only states that you have added a single trigger which is consumed by your Google Account working on the said script file.
These limitations take effect on a per user basis, not on a per script count.
For context for other community members in this page: https://developers.google.com/apps-script/guides/services/quotas you will find this and other limits that apply to Apps Script projects, triggers and function executions.
In your use case this won't be a problem. You will be creating projects and triggers in a 1 : 1 ratio. Apps Script allows up to 20 triggers per project.
You can share that project with someone and this person will be allowed to create 20 more triggers. If you create a new Apps Script project you will be able to create more triggers in the new project.
Trying to create additional triggers will result in this error message:
Exception: This script has too many triggers. Triggers must be deleted from the script before more can be added.
I manage a large Google spreadsheet where I use apps script to automatically sort and format form responses by using time-based triggers.
This sheet and many more like it are owned by one google account, not the ones who manage the individual sheets.
I have noticed that the performance of my scripts is very inconsistent over time. One minute they execute in 10-30 seconds, then they keep timing out for 2 hours, just to then suddenly work again. This happens regardless of what the actual script is and whether it is run by a trigger or manually.
I know that one of the limitations of Apps Script is 30 simultaneous executions per user.
So my question is: Does that limitation apply to the owner of the apps script project or the one who set up the triggers and runs the scripts?
Because if it's the former, then maybe the reason for the performance issues is that there are dozens of sheets fighting over those 30 execution slots?
Quota call is attributed to the user running the script. The "user running the script"/the effective user is different in different circumstances. In case of
Instance
Whose quota?
Script editor "Run"
User at the keyboard
Menu "Run"/Button click
User at the keyboard
Simple triggers
User at the keyboard
Installable triggers
User who installed the trigger(regardless of who is at the keyboard)ref
Custom function
User at the keyboard
Webapp(execute as me)
User who installed the trigger(regardless of who is at the keyboard)
Webapp(execute as user accessing)
User at the keyboardref
Quota calls are not attributed to the owner unless the owner satisfies any of the above criteria.
Reference:
User identity/permissions
I'm setting up an event to encourage people to stay physically active. Once someone registers, they are sent a copy of a Google Form/Sheet template that they will use to create their team. Each member of the team will enter their name, select the activity that they performed and record how long they performed it. The log Form should automatically update to list these names and activities so that the users can select from this list later rather than enter them again. The linked Response spreadsheet has charts comparing the team members activities to each other. I have a 'master' spreadsheet that imports the data from all of the team's response sheets and compares and displays them (on Google Slides) for the participants to view.
The problem that I'm having is that I would like to be able to programmatically authorize the Log Form auto update so that I don't need to do it manually every time a new Log Form is generated.
Things tried:
1) Form ranger - the Form ranger configuration can be setup in the form template, but is lost once the template is copied, requiring me to reconfigure (and authorize) the Form Ranger each new form as it's generated.
2) Use Google script to update the form with an onFormSubmit trigger. Process is working but I need to manually setup the onFormSubmit trigger, the first time, in each new Form/Spreadsheet in order for it to continue automatically afterward.
3) Updated the manifest file to include: "oauthScopes": ["https://www.googleapis.com/auth/spreadsheets.currentonly"] When I tried this, the script generated an error indicating 'You do not have permission to call SpreadsheetApp.openById'. It began working again after removing the '.currentonly' but still required me to manual authorize it for each new Form/SS.
4) Added
/**
* #OnlyCurrentDoc
*/
to the script. This added several seconds to the script runtime but, other than that, I didn't notice any change. Still required me to manually authorize.
5) I've tried using simple triggers (onOpen and onEdit) to detect changes in the Form's linked Response sheet, but found that these triggers are not activated with the form's automated sending of data to the spreadsheet but rather when the USER manually performs the operations on the spreadsheet. So still no automated updating.
Do you have any other ideas? I appreciate any assistance that you can provide.
Thanks,
David
This question already has answers here:
Summary of failures for Google Apps Script: Not found
(2 answers)
Closed 5 years ago.
I am getting below email on daily basis. How to stop it??
Summary of failures for Google Apps Script: Eml Manager
If you are not supposed to be running any scripts then you can just open the script editor, click on Resources → All Your triggers and then remove triggers you do not want. You can also simply disable notifications by clicking on the Notifications link to the right of the trigger and removing your e-mail.
Otherwise, in a similar manner, go to the Eml Manager and fix the code :)
If you are getting 'Summary of failures for Google Apps Script' on daily basis, you should look forward to fixing your code because code isn't behaving as you had expected.
Here are few of the reasons which can cause those failure emails:
Too many simultaneous invocations on the google app to which you have attached your appscript
Authorization or Authentication issue (a new user of the script has to authorize it first time)
Script took more than 6 minutes to complete (6 min is the limit)
If you have created programatical triggers, and forget to delete them once it has served the purpose, it will keep on creating new triggers and there is total trigger limit per script is 20.
In some cases, server can also be too busy to trigger your script but that rarely happens.
Also, if your script is taking too longer to complete, you should look forward to reducing the looping and also reducing writing operations on google apps(as it keeps on saving every change you made). Also, use in built formulas etc as much as possible.
If your code is totally fine according to you, then you can stop those failure emails by removing your name from the notifications option of your triggers as #Vytautas mentioned.
Is there any way to make Google Script call functions asynchronously? My scenario is that I have a main spreadsheet that information is entered into and a script then passes the relevant information to other spreadsheets.
There are then other functions that manipulate the data in those other spreadsheets. Unfortunately, because of the high volume of data, calling all the functions on one action causes the script to hit the 6 minute time out.
I tried using the onEdit trigger in the other spreadsheets, but it doesn't seem to work unless the sheets are opened by a user.
The way it is just now the user would have to hit 4 different buttons to trigger the various functions and not get a time out.
Thanks for any help
Blair
Depending on how realtime the updates need to be, you could consider creating a queue that contains all of the updates to be made (perhaps stored in the PropertiesService as a stringified JSON object).
Then your update code could be triggered regularly, say every 5 minutes, and read the next element of the queue and execute the update, before removing that entry from the queue. This would mean each individual update fitted within the 6 minute window, but it would also mean that if there were 4 additional updates for every update to the main sheet it might be up to 24 minutes before all of them had been made.