View any trigger execution of any user of your add-on

[Alan Wells]

Trick question.  Can you see a log for any and all trigger executions for all the users of your add-on?  Yes.  Every code execution ever run by every user of your add-on from a trigger is logged to the Apps Script Dashboard.

• Go to "My Projects" https://script.google.com/home/my
• Locate the project that the add-on is published from.
• Click the icon of the 3 stacked dots on the right
• Click "Triggers" from the menu
• You will see a list of triggers that are owned by "Other User" - In other words the user of your add-on.
• There's even a menu item for the trigger listing to "Open Triggering Container"  - But obviously, you can't open the users document that your add-on is installed in, unless they shared it with you.
• And there is no information about what user account the trigger is associated with.
• You can however get the Trigger ID of that execution.  But that won't help you in any way unless you knew what user account was associated with that Trigger ID.  And to do that, you'd need to keep a database of every Trigger ID with every user email.  Your add-on would need to get the Trigger ID when the trigger was created, then get the user email, and then somehow export that information to you.

I was a little surprised to find out that my Apps Script Dashboard can show logs for every trigger ID of every user who installed a trigger from the add-on.  It seems like a total waste of capability unless you can tie the Trigger ID to the user.  I can't inform the user that the code failed if I don't have their email address.  But I have my own error handling and error logging system, so I don't need that information anyway, EXCEPT in situations where my error logging won't work; like if the user has not authorized the permissions yet, or the authorization was somehow lost.

[Steve Webster]

Thanks for sharing Alan.

A privacy thought: This reminds me of when I wrote some add-ons for an educator. We thought it was best to not get student email addresses, but we wanted some tracking. We ended up using the "Session.getTemporaryActiveUserKey()", which "gets a temporary key that is unique to the active user but does not reveal the user identity. The temporary key rotates every 30 days and is unique to the script."

In other words, metric reports, StackDriver Logs, or other storage can have reporting with this temp user key. As I ponder a bit more, I suppose it is possible to have the add-on or app communicate to the user using it.

Kind Regards,

Steve Webster

SW gApps LLC, President 

Google Product Expert in: Google Apps Script, Drive, and Docs 

Google Vendor (2012-2013) || Google Apps Developer Blog Guest Blogger 

Add-ons: Text gBlaster and Remove Blank Rows

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/1b81c937-53d7-435a-b0a1-e6718f93846f%40googlegroups.com.

[Alan Wells]

Google discourages the practice of having personal information, like user emails, logged to Stackdriver, even though it is possible.

https://developers.google.com/apps-script/guides/logging#using_stackdriver_logging

If the developer initiated the logging of personal data to Stackdriver, then Google could state that it's not their fault, so don't fine us.  I don't blame them.  That's what I'd do also. 

What could be done, is to encrypt the email.  But if the user doesn't want their email known, then encrypting it, ultimately won't comply with the users wishes.

Using the Active User Key assumes that the user is going make a note of their key, record it, and then contact you with the provided key.  Good luck with that.  But, that may be all that your left with unless you want to make it clear in your Terms of Service and Privacy Policy that in some cases the account email might be sent to you.

If there is an error, and email service is authorized, the code can send an email from the account to itself.  That way the information isn't being transmitted outside of the account.

I am very much in favor of protecting user information.

To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-community+unsub...@googlegroups.com.

[Kim Nilsson]

Yes, and so are all users, and us admins working to get awesome tools in their hands.

We don't want to be blocked (for data privacy reasons) by the fact that developers are getting access to data they don't really need.

However, I do like the part where the code itself could report back errors to the user, without any user details reaching the developer side.