I have a web app that creates a process that can take well above 6 min to complete. I have decided to chunk it out using timed triggers and scriptDB to track execution process.
I have my web app shared within our organization, to execute as the user accessing it.
Are the script triggers created as the user, or as the script-owner in this case?
If your script is set to execute as the user accesing it, then the triggers are created under the user's account and not the owner of the script.
Related
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 have created 1 google app script project. which sends me an email every morning with schedule and tasks.
It has .gs script
And a trigger to execute everyday
If I want to share this with other users, haw can I share with them?
Do I need to share the code and trigger or is there any good way to share apps script.
These are the currently available methods to distribute:
Add on
Published add ons are very useful in distributing the functionality of the script with many users
Unpublished add ons can be shared directly by sharing the script. They have a lot of restrictions.
Simple triggers(like onOpen) are triggered automaticallyref.
Installable Triggers(like onChange) are managed by the script per user
Library
Users need at least read access to the script
Triggers are not shared
End users still need to create their own apps script, which accesses the library
Web app:
Variety of distribution options
If you don't want to share source code, you don't have to, but the web app should be published to run as yourself and should be accessible to "anyone"
Triggers are managed by the script. Installable triggers can be created per user. But simple triggers cannot be triggered "directly" from a http GET/POST. However, simple triggers are triggered in the project itself that is bound to a document(say, Google sheets)
End users still need to create their own apps script, which accesses the web app using HTTP requests GET or POST
google-apps-script-api?:
This is mostly used to run your script as yourself without accessing the code editor, but can also be used to distribute if both the calling project and the target project uses the same GCP
Under most circumstances, you'll be restricted to less than 100 end users, except in case of published add ons or web apps(set to execute as the end user)
You can publish the script as a web app and set the app to execute as the authenticated user.
When your users launch the web app, they would authenticate the app with their own Google account credentials and the triggers would be added to their account.
With this approach, there's no need to create the script's source code with your users.
I've been developing an apps script project for my company that tracks our time/expenses. I've structured the project like so:
The company has a paid Gsuite account that owns all the spreadsheets hosted on the company's google drive.
Each employee has their own "user" spreadsheet which is shared from the company Gsuite account with the employee's personal gmail account.
Each of the user spreadsheets has a container-bound script that accesses a central library script.
The library script allows us to update the script centrally and the effects are immediate for each user. It also prevents users from seeing the central script and meddling with it.
Each of the user container-bound scripts have installable triggers that are authorized by the company account so that the code being run has full authority to do what it needs to to the spreadsheets.
This setup has been working quite well for us with about 40 users. The drawback to this setup is that since all the script activity is run by the company account via the triggers, the activity of all our users is logged under the single company account and therefore capped by the apps script server quotas for a single user. This hasn't been much of an issue for us yet as long as our script is efficient in how it runs. I have looked into deploying this project as a web-app for our company, but there doesn't seem to be a good way to control/limit user access to the central files. In other words, if this project was running as a web app installed by each user, each user would need to have access to all the central spreadsheets that the project uses behind the scenes. And we don't want that.
SO with that background, here is my question. How do I efficiently track apps script activity to see how close we are to hitting our server quota, and identify which of my functions need to be optimized?
I started doing this by writing a entry into a "activity log" spreadsheet every time the script was called. It tracked what function was called, and who the user was and it had a start time entry and and end time entry so I can see how long unique executions took and which ones failed. This was great because I had a live view into the project activity and could graph it using the spreadsheet graphs tools. Where this began to break down was the fact that every execution of the script required two write-actions: one for initialization and another for completion. Since the script is being executed every time a user made an edit to their spreadsheet, during times of high traffic, the activity log spreadsheet became inaccessible and errors would be thrown all over the place.
So I have since transitioned to tracking activity by connecting each script file to a single Google Cloud Platform (GCP) project and using the Logger API. Writing logs is a lot more efficient than writing an entry to a spreadsheet, so the high traffic errors are all but gone. The problem now is that the GCP log browser isn't as easy to use as a spreadsheet and I can't graph the logs or sum up the activity to see where we stand with our server quota.
I've spent some time now trying to figure out how to automatically export the logs from the GCP so I can process the logs in real-time. I see how to download the logs as csv files, which I can then import into a google spreadsheet and do the calcs and graphing I need, but this is a manual process, and doesn't show live data.
I have also figured out how to stream the logs from GCP by setting up a "sink" that transfers the logs to a "bucket" which can theoretically be read by other services. This got me excited to try out Google Data Studio, which I saw is able to use Google Cloud Storage "buckets" as a data source. Unfortunately though, Google Data Studio can only read csv files in cloud storage, and not the json files that my "sink" is generating in my "bucket" for the logs.
So I've hit a wall. Am I missing something here? I'm just trying to get live data showing current activity on our apps script project so I can identify failed executions, see total processing time, and sort the logs by user or function so I can quickly identify where I need to optimize my script.
You've already referenced using GCP side of your Apps Script.
Have a look at Metric explorer, it lets you see quota usage per resource and auto generates graph for you.
But long term I think re-building your solution may be a better idea. At minimum switching to submitting data via Google Forms will save you on operation.
I have a Google Apps Script that is shared with another user (I own both users - one is my personal Gmail and one is my work account on Gsuite). The script scans threads in my inbox, and applies labels to the threads based on rules.
I set up time-based triggers from each user account to run the script.
The script calls Session.getActiveUser().getEmail() to identify which user is running it, and sets some parameters differently depending on the user.
Logging shows that, for either user, the script errors about half the time, intermittently, saying "The script does not have permission to get the active user's identity." (Clearly it DOES have permission, for each user, or else it would fail every time.)
To troubleshoot this, I stopped sharing the script between users. I made separate copies of the same code, in each user's account. Now the script is running fine for both users.
Can anyone confirm that this is a bug in Google's operating environment? That (I suspect) somehow the operating environment gets confused about which user is running the shared script?
(I did search this forum and can't find a description that explains it)
You should be using getEffectiveUser(), since there is not necessarily an active user when the time-based trigger triggers.
From the documentation (linked above):
If the script is running under an installable trigger, this returns
the account of the user who created the trigger.
According to Google app script time-trigger documentation https://developers.google.com/apps-script/guides/triggers/installable#limitations,
Time-driven triggers cannot run more frequently than once per hour. How can I use app script to write an add-on that process large amount of data?
If I run a trigger, it will only allow me to trigger once. I can't chain the triggers so it can continuously run.
You cannot do so using triggers because they would run at most once per hour in the context of an add on.
What you can do is to initiate such processing client-side while possibly showing progress on a sidebar. The client js in the sidebar can chain server calls.Of course being all client-side means the user must have opened the file and if they close the browser tab or navigate away, the chain calls will stop. That can be handled by alerting the user and making them aware that a "sync" happens and sometimes takes a while. Currently there is no other way to handle this unless your client call and time trigger call another server which does the processing, like appengine or gce.