Accessing the Gmail mailbox by bot written in Apps Script - google-apps-script

I am creating a Google Chat bot using Apps Script.
It has to check every x minutes my team's mailbox for some upcoming messages. I used a Gmail service to achieve this functionality.
Is there any option to that the function that is responsible for checking could be run as that certain user (eg. myteamsmalibox#gmail.com)? As for now, I got all my code working but the function is running through my own mailbox.

Related

Apps Script (Google Sheet) not allowing me to Run Script

I have a fairly simple dataset in a Google Sheet. I created an AutoSort script. I saved it, and when I click "Run," I get the following errors. One from a pop-up, and another from the Execution Log.
Pop-up error:
Authorization required
This project requires your permission to access your data.
*For this error, there is a button to "Review Permissions" and I log in using my google account and then just nothing happens.
Execution Log error:
Warning This project requires access to your Google Account to run. Please try again and allow it this time.
The Owner of this Google Sheet is my personal Gmail account, and I am making these edits and created the script using my business Gmail Admin account. I also tried to access this sheet and run the script USING my personal Gmail account, and received the same error:
Google hasn’t verified this app
The app is requesting access to sensitive info in your Google Account. Until the developer ({mypersonalemail}#gmail.com) verifies this app with Google, you shouldn't use it.
Any insight as to how I can authorize this would be appreciated. It sounds like something small I'm missing.
Also, in my personal email I receive a message with subject:
Review edits to your Apps Script project within your document
and it allows me links to access the worksheet and the script, but I don't see any way to approve the edits, or anything like that.
Expected behavior: What I am expecting is for the script to Run, when I click "Run."
It's not a good idea to mix accounts from different domains, specially when using a free account and a Google Workspace account like you have done because that is the cause of the situation that you are facing.
My hypothesis is that the Google Cloud default project linked to the bounded script is created with the account used to create the project.
If you need that you personal account be the spreadsheet owner the best is to create the script using the personal account, and when needed, create a Google Cloud Standard project (GCSP) using the the personal account. You might try to fix the problem with your spreadsheet and the current Apps Script project by creating a GCSP, as was mentioned previously, by using the account that is the owner of the spreadsheet and linking it to the Apps Script project.
Note: If your script is using sensitive scopes you might have to set the OAuth Consent Screen publishing status to tes and add your Google Workspace account as tester.
Ref: Setting up your OAuth consent screen
Once you have finished the setup of your Google Apps Script project you should be able to use your Google Workspace account to update and run the Apps Script code but any new deployment and new version should be done using your personal account.
If you have access to Shared Drives and are allowed to use them for your spreasheet, consider to move it to a Shared Drive as this will make a lot easier to manage your script.

How to share or distribute google apps script with other users?

I have created 1 google app script project. which sends me an email every morning with schedule and tasks.
It has .gs script
And a trigger to execute everyday
If I want to share this with other users, haw can I share with them?
Do I need to share the code and trigger or is there any good way to share apps script.
These are the currently available methods to distribute:
Add on
Published add ons are very useful in distributing the functionality of the script with many users
Unpublished add ons can be shared directly by sharing the script. They have a lot of restrictions.
Simple triggers(like onOpen) are triggered automaticallyref.
Installable Triggers(like onChange) are managed by the script per user
Library
Users need at least read access to the script
Triggers are not shared
End users still need to create their own apps script, which accesses the library
Web app:
Variety of distribution options
If you don't want to share source code, you don't have to, but the web app should be published to run as yourself and should be accessible to "anyone"
Triggers are managed by the script. Installable triggers can be created per user. But simple triggers cannot be triggered "directly" from a http GET/POST. However, simple triggers are triggered in the project itself that is bound to a document(say, Google sheets)
End users still need to create their own apps script, which accesses the web app using HTTP requests GET or POST
google-apps-script-api?:
This is mostly used to run your script as yourself without accessing the code editor, but can also be used to distribute if both the calling project and the target project uses the same GCP
Under most circumstances, you'll be restricted to less than 100 end users, except in case of published add ons or web apps(set to execute as the end user)
You can publish the script as a web app and set the app to execute as the authenticated user.
When your users launch the web app, they would authenticate the app with their own Google account credentials and the triggers would be added to their account.
With this approach, there's no need to create the script's source code with your users.

How to continue using google scripts?

Google sent me an email to do app verification to be able to continue using the gmail api. My app is basically a bunch of scripts running in spreadsheets that send an email notification when a change occurs.
Having to get a gsuite account and going through App verification to allow my scripts to survive seems very heavy process.
Does anyone know if all these spreadsheet scripts will now be stripped of their ability to send emails in the new year? or if they can continue as long as you are running them only under your own account?
I have not been able to see any documentation on this to confirm one way or another.
Seeing process described for verification here: Google app script verify scares me!

Publishing Google Sheets Addon - site verification

I've built a Google Sheets script that queries my company's API and outputs the data from my platform into a spreadsheet. It takes the username and password using a form and then runs an API call to output the results to Google Sheets.
When I tried to publish the addon, I received feedback that I needed to comply with Google OAuth verification. To get this verification, I need to prove that the domain is mine; although I have access to GA for our site (which isn't working for the verification), I am not the domain owner. So, I was wondering, is there a way to publish this Google addon for my company account and what are the next steps to complying with Google OAuth?

How to add a Google Apps Script web app as a client in Google API console

I have an app that consists of two parts
an installed application (more specifically: a browser add-on) that runs on the user's machine, and
a web app implemented as a stand-alone Google Apps Script app using HtmlService.
The two parts talk to each other and both access some Google APIs on behalf of the user via Oauth. To do this, I set up an API project in the Google API console. In the section "API Access", I created a client of type "Installed Application" for the browser add-on. For the Apps Script part, Google takes care of the authorization flow automatically.
My problem is that Google does not know that these two clients are part of the same project. Therefore, the user has to go through two authorization steps in a row when executing my app for the first time (first, the Oauth process for the browser add-on and then the automatically generated authorization process from Google Apps Script). This is very confusing to the user, especially, since the splitting between the browser add-on and the web app is rather an implementational detail about which the user shouldn't really have to bother.
Is there a way to unify the two authorization flows? I know that one can add several distinct clients to a single project in the Google API console. It seems to me like this feature is explicitly intended for scenarios similar to mine, where more than one application make up what is perceived as a single service by the user. Unfortunately, web apps that are implemented in Google Apps script don't seem to be compatible with the Google API console because of the way Apps Script generates the authorization flow automatically. Or am I missing an option in the API console or in the Apps Script editor?
For future reference: I found out that Google automatically creates an API project in the Google API console for each Google Apps Script project. This seems to be a fairly recent feature. One difficulty for me was that these API projects don't show up when one goes to the API console, clicks on the name of whatever project is currently opened in the upper left corner and chooses "open". Apparently, the only way to reach the auto-generated API project is as follows:
Go to drive.google.com and open the Google Apps Script project.
Chose "Resources --> Use Google APIs...".
In the popup, click the link to the Google API console.
In principle, this should allow to add additional clients to the project, as long as none of the other clients is also a Google Apps Script project. I haven't been able to test this since it still doesn't solve my specific problem: Sending e-mails from the user's Gmail account seems to be a feature unique to Google Apps Script and I couldn't find an Oauth2 scope for this operation. Therefore, I still cannot ask for all required permissions in a single authorization flow. But if anyone who's reading this has a similar problem with different Oauth2 scopes, the above instructions should fix it for you.
Anyway, I solved my problem in the meantime by no longer using Google Drive to upload files.