Is there anyway to delete "other user" installable triggers? Being lucky enough to guess which user to delete only shows their trigger as disabled but still requires you log in their gmail to delete it which is kind of concerning when you are the "owner" of the spreadsheet?
You can't delete other user's trigger. A trigger to a script is associated with a user's Google account (and the script project).
What they do with their trigger is their own business. As the owner, you can decide if a user has the privilege to edit/view your spreadsheet. If a user has been provided with edit access, He can choose to use that privilege any way he sees fit. For example, He can choose to respond to any edit made to the sheet manually or programmatically through a script at his disposal.
If you want to know who made a particular edit, you can see the edit history of each cell.
There is no way to remove other users triggers.
Triggers are associated with the Apps Script project, not to the Spreadsheet file.
Users are able to create Apps Script Projects on any spreadsheets they have Edit access to.
If you do not want users creating Apps Script Projects on your spreadsheets, give them Read-Only Access.
The spreadsheets that already have other users triggers on them can only be "purged" by removing access.
You can permanently delete a script with all of its installable triggers after making a clean copy of it.
Go to the Overview section in the new Apps Script editor.
Click the 'Make a copy' button.
A new browser tab will be created with the new script on screen, then click the 'Delete project' button in the old script.
You can now add the triggers you need manually or by code.
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.
I have a complex spreadsheet where most of the sheet is locked and the user can only edit a handful of cells which triggers a bunch of calculations. This used to work fine but the problem now is I have added a drawing which I attached a script to so it acts as a button. Doing this forces the user to have to authorize and now the scripts run as that user so when the script tries to update cells that are locked to the user it fails.
How can I make it so a user can't type into cells, but my scripts can still update them. Basically I want the script to have full access to the sheet, not restricted by user permissions.
Workaround#1 -Service account:
Create a service account
Share your spreadsheet with edit permissions to the service account's email
Install and Use the Google oauth2 library to get Bearer token with necessary scopes(Drive/Sheets/Both). This token can be used to impersonate the service account.
Using the bearer token above, You can directly access the
google-sheets-api using urlfetch
OR use a published webapp(set to execute as "User accessing the app" and "Anyone") to use inbuilt services such as SpreadsheetApp. See Second related answer linked below.
In this case, PRIVATE_KEY of the service account acts as a password to access the spreadsheet with edit privileges. So, exposing it directly in the script editor will give access to any of the editors to access protected areas of the spreadsheet and all service account resources. So, in a way, protected areas are not protected in a absolute way. If protected areas need to be absolutely protected, You may be able to bypass this limitation
using two script projects: a bound one posting data to a unbound one, which is published as a web app and holds the private key. Here, editors can be supplied with passwords to access the unbound script.
Another way is to simply publish a addon, as a addon's source code is never visible to end users.
Workaround#2 - Installable triggers:
Use a installable edit trigger with a checkbox. Users click a checkbox in the unprotected area and script modifies the protected area.
Installable triggers run under the authority of the user who installed it and not as the current user.
They can bypass permission restrictions of the sheet. But this is a double edged sword. Anyone with edit permission will be able to trigger the script. Not only that, they may also be able to access the script editor and modify the script as they see fit. To limit foul usage,
Set the script to run only at a specified version: This can be done by setting the edit trigger manually in Tools > Script editor> Edit > Current project triggers > Add trigger > Select version. Script must have a saved version and be deployed as a webapp(doesn't need to be working).
Avoid providing unnecessary scopes to the script. Limit oauthScopes by editing manifest file. Preferably the only scope provided should be https://www.googleapis.com/auth/spreadsheets.currentonly
Related:
Is there a way to let a user edit another spreadsheet with a script and hide it from him at the same time?
Google App Script execute function when a user selects a cell in a range
I have a trigger set by another user. I tried to edit or delete it but there is no option for that actions. See the picture below. Is there any way to edit it?
Apps Script triggers belong to the user who created them so unfortunately there is no direct way for you to edit/delete those triggers.
Possible solution
If the account of the user who created the triggers is under the same G Suite domain you should be able to contact your G Suite administrator in order to reset their password. In this way, you may be able to get access to the new credentials and change the triggers yourself.
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.
I am trying to build a method for creating a shared contact group. The API's are there so that if an editor clicks snyc contacts it can snyc with "Their" own contacts. But I am not sure how to make that work as an automated trigger. I am OK with each editor authorizing, but can each one have their own timed trigger?
UPDATE: This issue is moot as each trigger is already set to the users.
It is not possible in Apps Script to have a script that allows a user to create triggers for other users directly.
As stated, it is possible to create a menu item or UI control that will allow users of a script/add-on to create triggers for themselves. The Form Notifications add-on has an example of this, where a sidebar control creates or removes form submit triggers for the user of the add-on.