I have created trigger programmatically on the user's profile. It's working as required since couple of months.
Last week I have changed the code of trigger program and published. But still, users are getting authentication pop up.
Do I need to programmatically delete the existing trigger of all users profile and create again?
Or any other option could you suggest
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 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'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
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
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.