Shared script conflict using Session.getActiveUser().getEmail() - google-apps-script

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.

Related

Too many time based triggers in Google Apps Script

I have a published add-on on the Google Workspace Marketplace. Suddenly users have started getting the error
This add-on has created too many time-based triggers in this document
for this Google user account.
However, when I have the add-on log what triggers are installed, there are only three, and only one of them is time-based.
What I've started noticing, though, is in the master script file (the one I edit and then publish), when I look at triggers, there are a large number of triggers that are listed as being installed by "Other User." To be clear, there are no shared users on this spreadsheet or the script attached to it. Are these "Other User" triggers coming from users of the add-on?
Otherwise, I don't know what the above error would be referring to. But I also don't understand why the triggers for every user of the add-on would install in the master script.
I also went in and editing the code where the triggers are installed for each user to FIRST delete all instances of that trigger before installing it - same error.
I went a step further and made a button just to delete every single trigger - same error.
From the documentation:
Each add-on can only have one trigger of each type, per user, per document. For instance, in a given spreadsheet, a given user can only have one edit trigger, although the user could also have a form-submit trigger or a time-driven trigger in the same spreadsheet. A different user with access to the same spreadsheet could have their own separate set of triggers.
You may want to create any triggers you need in the onInstall(e) function so that they only get created once. That way, you do not need to delete and recreate the triggers every time the add-on runs.

Google Apps Script: does the 30 simultaneous executions limitation apply to the owner of the script or the user who executes it?

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

Differentiate User and Owner Info in Apps Script Installable Trigger

When I call Session.getActiveUser() from a function called by an installable trigger (e.g. an OnOpen Event trigger in Google Sheets - but not the Simple Trigger) in Apps Script, what user information am I getting?
I understand that installable triggers run under the owner/creator of the trigger regardless of who has opened the sheet. So would this always return that person's info?
Either way, how do I get the information of the other person? (e.g. if it gives owner info, how do I get the info of the user actually opening it - and vice-versa)
Update:
I got another user to test my script. I watched the logs while they were in the file, and it definitely reported THEM as the user, even when the installable OnOpen trigger was triggered.
This is good from the perspective that it showed them the correct menu options - he and I saw different menus per my OnOpen script, which is what I want.
However, this raises two issues for me:
This seems to go against the Google Documentation, which states: "Installable triggers always run under the account of the person who created them. For example, if you create an installable open trigger, it runs when your colleague opens the document (if your colleague has edit access), but it runs as your account. This means that if you create a trigger to send an email when a document is opened, the email is always sent from your account, not necessarily the account that opened the document."
In a future function, I will be calling an API from another App. This API will need my credentials (API ID and Secret). I was hoping / expecting that I could "sandbox" my credentials in an installable trigger - invisible to other users - that will allow them to use my credentials just for the specific functions which I would script into the API. If the installable trigger is in fact, NOT using my credentials, then how can I do this? I don't want to have to make every user go to the other App and generate their own set of API credentials, that will be unsustainable in this organization, and not everyone should need to do that.
It should return whomever triggered the script. But it depends if the security policy does allow you to access the user's identity. Seeing the documentation:
Gets information about the current user. If security policies do not allow access to the user's identity, User.getEmail() returns a blank string. The circumstances in which the email address is available vary: for example, the user's email address is not available in any context that allows a script to run without that user's authorization, like a simple onOpen(e) or onEdit(e) trigger, a custom function in Google Sheets, or a web app deployed to "execute as me" (that is, authorized by the developer instead of the user).
I have tested it and even an installable trigger won't return anything if it belongs to a different organization.
But you might be able to if other users belong to the same organization.
However, these restrictions generally do not apply if the developer runs the script themselves or belongs to the same Google Workspace domain as the user.
Workaround:
One thing I guess would be to assign the triggered function into a button and have the users click that upon opening the sheet. Via clicking the button, I have been able to show the User object using that method.
Or a webapp that will serve as a relay and will get the User details.

Google App Script and PropertiesService.getUserProperties()

I use the google app script in my google spreadsheet document.
The settings of each user of my spreadsheet doc is saved in:
var userProperties = PropertiesService.getUserProperties();.
To save the settings I use
PropertiesService.getUserProperties()setProperties({some properties}, true)
The problem is the first user saves his settings and another users get the settings of the first user using PropertiesService.getUserProperties()
But they should not, they should get own settings.
Do you have any idea how it is possible?
They must be logging in with the same user account for this to happen; a user can only ever access their own user properties. This could be because any triggers were created on your own account (say for form submissions), or web apps were deployed to run as you.
Share a copy of your sheet (andrew#roberts.net) if you would like me to a take a deeper look.
In fact as the support answered me, it is not a bug. I had wrong user properties on handling triggering event.
User properties are private to the user executing the script. However, when you setup an installable onEdit trigger, the code always runs as the user that setup the trigger:
"... runs with the authorization of the user who created the trigger, even if another user with edit access opens the spreadsheet."
https://developers.google.com/apps-script/guides/triggers/installable
Since the code always runs as the same user, it's always accessing the same user properties. In general it's not possible to get the identity of a user if they haven't authorized the script.

Google Forms with script transfer of ownership still runs script as previous user

I made a google script in a spreadsheet that responds on form submit. It modifies the files, makes a pdf and emails that pdf to specific people. This was made for someone else and then I transferred ownership. However, the edits to those files and emails sent, still appear under my email. How do I completely transfer the folders and everything in them a different user on the same domain so that they are the ones sending emails and modifying files?
You need to go into the script and add a function that calls ScriptApp.invalidateAuth https://developers.google.com/apps-script/reference/script/script-app#invalidateAuth() then call any function like doGet using the new account to reauthenticate
How do I completely transfer the folders and everything in them a different user on the same domain
When you transferred ownership of your files & folders, everything in them did get transferred.
... so that they are the ones sending emails and modifying files?
However, the TRIGGERS that you had set up previously belong to your account, not to the associated scripts.
You have a couple of options for stopping those triggers from running as you.
Disable specific installable triggers.
If you still have access to the offending script, open it in script editor, go to resources > Current project's triggers, and disable the triggers. Done.
If you don't have access to the script anymore, open the script editor on any of your scripts, go to resources > All your triggers, and disable the triggers if you can identify them. This can be challenging if you use the same names for trigger functions in multiple scripts, as there is no indication here of which script they came from.
De-authorize the offending script.
As Zig's answer describes, if you still have access to the offending script, you can add a function to revoke authorization, and run it from your account.
Alternatively, you can see all scripts that you have authorized, and revoke access directly. Go to your Account Settings page, and select "View all" under Connected apps and services, or use this link.
Select the offending script, then click "Revoke access". Done!
To get the script running under the new owner's account, you need to repeat whatever steps set it up for you, including authorization from their account.