I'm having trouble understanding the collective user rights to trigger deletions.
I know that installable triggers can only be deleted by the user who created them, but the verbiage in the Google Scripts page seems to infer that programmable triggers (written in the actual code) can be removed/deleted by other users.
If so, why is that when I run a script to delete all triggers from another user's computer, it won't delete the trigger that I programmed from my computer?
This other Stack Overflow page is close to addressing the issue but only seems to talk about installable triggers (if I'm not mistaken).
/**
* Creates a time-driven trigger.
*/
function createFirstTrigger() {
// Trigger every 6 hours.
ScriptApp.newTrigger('message')
.timeBased()
.everyMinutes(1)
.create();
}
function deletingAllTriggers() {
// Deletes all triggers in the current project.
var triggers = ScriptApp.getProjectTriggers();
for (var i = 0; i < triggers.length; i++) {
ScriptApp.deleteTrigger(triggers[i]);
}
}
I've also tried deleting the original code for the trigger from another person's computer, but the trigger continues to live on.
Users can not delete each other's triggers.
The user who is having the issue, can open up their triggers page
Review all their triggers, and delete any triggers that they want to stop.
That user can also go into the security section of their account and review permissions given to third party access.
https://myaccount.google.com/security-checkup
If the admin of a GSuite account needs access to a users file, what the admin should do depends on whether the user is still employed in the organization or not. If the user is no longer at the organization, then the admin must:
Remove company data from any of the users company devices
Change the users password - Record the new password - you'll need it
Reset sign-in cookies
Revoke all application specific passwords
Login in to the former employee's account using the new password and remove all recovery phone and email addresses
Transfer file ownership of files that are still needed by the organization to other user(s)
Make a copy of all data in the users account - https://takeout.google.com/settings/takeout
Delete the users account - There's no point in paying for an account that no one is using
If you want to stop a trigger from working at some specific date/time, then you could hard code a date into the trigger code to delete itself. If you don't want to hard code it, you could put the date into Properties Service - Script Properties, so that any of the file owners could manually change the date.
When the trigger runs, it doesn't matter whether the user still has access to the file or the code. The trigger will run regardless of whether the file owner has access to the file or their account, so the trigger can delete itself.
If you haven't written the function code to delete the installed trigger that runs it, then you'll need to have access to the users account. If that user is not available, then someone would need to log into their account. I'm not advocating for people to give out their password so that someone else can log into their account, I'm just stating what would need to be done.
The admin of a GSuite account can reset a users password, and then log into the account with the new password.
If the account that needs the trigger deleted, is a free/consumer account, then there is no way to get access to that users account.
If the code that created the trigger was in an add-on, then the add-on code could be written to check that users trigger, and delete it. That's assuming that the add-on was already authorized to create and delete triggers. For an add-on inside of a GSuite account, the add-on owner could write the code and publish the add-on within the company without needing the code to be reviewed by Google.
If the file with the trigger had been put into a Shared Drive, then other users would have access to that file. However, if you wanted to use an add-on, then add-ons can't currently be installed in files in a Shared Drive.
Documentation for Google Shared Drive
Related
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.
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.
I want to make a username available for someone else named after the old Tech Admin, however they have a ton of triggers running.
If I delete this user, is there a way to preserve these triggers or transfer them. Or are they affected at all with deletion?
From Installable triggers:
Installable triggers always run under the account of the person who created them.
The trigger owner is the user who installed it. There is no way to transfer this ownership.
(Trigger ownership transfer is not possible even if all options are checked when transferring data on user deletion, and even using Data Transfer API).
Even though I've seen reports (example) of triggers running in the background undesirably after the user has been deleted, from my experience, when the user is deleted (either removed from the script or the account is deleted), the trigger stops running, being commonly labeled as Disabled.
Therefore, if you want to delete this account, I'd suggest you to install these triggers again with another account.
File a feature request:
I'd suggest you to file a feature request in Issue Tracker using this template if you want to add the ability to transfer trigger ownership.
I have a problem with triggers and permissions in Drive, about Forms:
There is a shared folder with Forms.
All these Forms are of my property (I'm the owner)
Everyday, some other user with editor permissions, copy one of them
to another shared folder.
That 'some other user' is the new owner of that copy.
That copy has a Script (like the original Form) that when you open,
it perform 2 actions:
Change the owner of the Form to me
Set up a trigger to delete the Form
The problem is, at the moment of create the trigger, that the Script doesn't notice that the owner has changed during the execution. So, I own the file at the end, but the script is not allowed to delete the file when the time comes, because is not me the "author" or owner of that trigger.
Is there a way to resolve this?
An installable trigger always runs on behalf of the person who created it - that is the person who authorized the trigger by signing in with his account
If your set-up is such, that a user needs to delete a form owned by you, he needs to do it on your behalf.
Possible configurations:
1. In corporate into the code a call to a Web App
If you deploy the WebApp as Execute the app as: Me and Who has access to the app:Anyone within [your domain] - then everybody who calls the WebApp by its deployment URL can execute it on your behalf (you can also pass parameters to the WebApp by addining them as a query string to the URL)
2. Use a service account with impersonation
This will ensure that a script always runs on the behalf of the impersonated user (can be you!), no matter who runs the code
See sample
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.