How to reload gmail add-on through background process using app-script - google-apps-script

May i get some help on the below points where i am using app-script to develop a gmail add-on:
How can we refresh gmail add-on with back ground process?
=> Here is my case, I need to display card with multiple sections which is the process of hitting multiple apis to fetch data and to display the card. For this initially we will show a card with minimal information to the user once i get information from api, i need to update the basic cards with complete information.
How can we trigger a function on every mail thread open?
=> Currently it works once for a mail, here as explained above point need to refresh a card once we fetch the data. If not, user will be seeing same basic information card every time he opens the mail.
From above mentioned issues for point one we are trying to get solution where we can hit service for certain interval of time to check data availability and if data exists then fetch data and update cards, i mean to say need a setTimeout function kind of thing, unfortunately we did'nt found this in app script and We found sleep/waitLock functions in app-script, but my services may take little time to fetch data as it connects though multiple services so we cant make the user to wait until the whole process is to be completed. So that we will show a card with basic information required then after need to auto refresh the cards once we fetch the data. we tried of keeping refresh button for the user to click and fetch the updated data but here we are losing user experience, trying for auto refresh with out user interference to get updated information.
Need a process / solution where we can auto refresh the card with out user interference after the data available at our end instead of making user to wait until the process to be completed.
Earliest reply will be more helpful for us.
Thanks.

If a data status on a third-party backend changes as the result of a user interaction with your add-on UI, it is recommended that the add-on set a 'state changed' bit to true so that any existing client side cache is cleared. See the ActionResponseBuilder.setStateChanged() method description for additional details.
The card-based interface in Gmail Addons is an Apps Script Service.
You can interlink it with other Apps Script services as well as implement API calls - everything within the same Apps Script file.
Gmail Addons contents automatically update every time the user opens a different e-mail or refreshes his browser.
Within your Apps Script code you can install time-driven triggers to run the data availability check with a customized frequency.
Consider to install for your users an Auto Refresh extension if you do not want them to refresh the card themselves.

Related

Firebase event is not showing in Event tab

I have created a event on my Firebase dashboard
and can see it in Debug View
But I cannot see it in Events Tab, it's not there and I cannot mark it as a conversation event, as I need to set it.
Creating one from conversations tab does not specify app platform, which I need it to be for my iOS app.
How do I fix this issue?
There's an intended delay before the data shows up in the Events page. The initial data logged usually takes up to 24 hours to display and 3-4 hours delay for the succeeding data. DebugView on the other hand, shows you data (from events, event parameters, and user properties) as Analytics collects the data. This is used to help you set up data collection, troubleshoot issues as issues arise, and understand a user's behavior as the user explores your website or app. For additional information about the delay in Analytics reporting, you can refer to this blog post.

Sharepoint Online scripting similar to Google Apps Script?

For several years we've had a Google Site setup on a non-profit G-Suite domain. This site is used once a year for a conference we hold with about 200 deleagates. The site is used by delegates for some simple stuff like reading documents, but there is a much more complex part of it too.
I've used Google apps script to write a system where users can do voting, speaker queueing, elections, and a daily checkin/rollcall. How it looks to users is they goto a page, and they see a "Vote Yes", "Vote No", and "Abstain" button. These are embedded Google apps script applets on the Google site page. Similar for the speaker queue and other functions.
On the backend, when a user clicks "Yes" or "No", the script submits a Google form on their behalf, with that answer. The form is tied to a Google sheet. Originally we had it directly append a line to a google sheet, but found with 200 people voting at the same time, we ran into performance issues and limitations with Google sheets.
The script then does stuff like de-deuplicate the results (incase someone voted multiple times), tabulates the results, and displays the results. This is all done on another page on the site that the officers running the conference can see.
For speaker queue, users basically click a button to say "I want to speak", and their names get added to a google sheet. The officers running the conference then call them up when it's their turn to speak. Users can also click a button to see where they are in the queue, and they'll get a response on the page like "You are currently number 3 of 27 users in the queue". They can also click a different button to remove themselves from the queue.
With that all explained, we're looking at potentially switching away from Google Sites, and considering Microsoft Sharepoint Online. The reason for this is we're using "old" Google sites, which Google has said will be shutdown at some point. "New" google sites currently does not support any scripting or API's at all, so it's impossible to redo our site in that system currently. They say API's are coming, but no details on what will and won't be available.
We have access to a free non-profits domain on Office365 (E1 tier) which gives us sharepoint online, active directory online, and $5k for free Azure credits.
So I'm asking you all here if there is some similar system available with O365/Sharepoint online. I'd want to change where all the data is stored to an SQL database, as storing stuff in sheets isn't ideal from any viewpoint, it's just the best option we had at the time. Ideally, the code for this would all live in the cloud like it does with Google. If I have to write code in Visual studio and upload it then I'm OK with that, but for maintenance purposes it would be really nice to have it all stored in the cloud and not need to install a thick app to work on it.
Basically we need the ability for users to login to a sharepoint site with their o365 account (we issue them the account), be able to interact with the site to send and receive data from SQL (which is running in Azure on same domain).
Can anyone point me in the right direction? It seems much more complex on the MS side, with way more potential methods for doing it (Graph, Sharepoint Addons, etc).
A couple photos:
Thanks!
I would like to provide a no coding solution here. If we want to code, then we can use SharePoint Add-in to do almost everything, such as collect user input and display data.
I've used Google apps script to write a system where users can do voting, speaker queueing, elections, and a daily checkin/rollcall. How it looks to users is they goto a page, and they see a "Vote Yes", "Vote No", and "Abstain" button. These are embedded Google apps script applets on the Google site page. Similar for the speaker queue and other functions.
On the backend, when a user clicks "Yes" or "No", the script submits a Google form on their behalf, with that answer. The form is tied to a Google sheet. Originally we had it directly append a line to a google sheet, but found with 200 people voting at the same time, we ran into performance issues and limitations with Google sheets.
I think we can create a Microsoft Form or Microsoft PowerApps to get user response. And then Store the data to a SharePoint list.
The script then does stuff like de-deuplicate the results (incase someone voted multiple times), tabulates the results, and displays the results. This is all done on another page on the site that the officers running the conference can see.
We can use Microsoft Flow to process the data, such as remove duplicated data. On the other hand, we can display results in PowerApps.
For speaker queue, users basically click a button to say "I want to speak", and their names get added to a google sheet. The officers running the conference then call them up when it's their turn to speak. Users can also click a button to see where they are in the queue, and they'll get a response on the page like "You are currently number 3 of 27 users in the queue". They can also click a different button to remove themselves from the queue.
We can do it in PowerApps.

Google Apps Script - Access to different account (contact-api) via OAuth2-authentication

Retrieve/Update Google-Contacts from Apps Script (Spreadsheet)
Environment Desc:
We have a shared spreadsheet belonging to a domain-account "PrimContact" where we also manage our contacts.
The spreadsheet is shared with selected users in the domain with r/w-access.
Workflow so far: after making changes to the spreadsheet persist those changes through script-call.
This api-call was authorized via clientAuth and as of a few days that won't work anymore.
Through clientAuth we were able to allow all the users to manipulate the sheet and finally update
the contacts of the targeted contact (PrimContact).
Problem:
Reading up about deprecation of clientAuth I tried, and somewhat succeeded, to change
authentication to OAuth2. As I understand things there are two ways I can authenticate a
user. Through a clientAccount or via serviceAccount.
SideNote: The following two pages helped a lot in getting it done, especially for serviceAcc.
[1]client account with: https://github.com/googlesamples/apps-script-oauth2
[2]service account auth with: https://github.com/mcdanielgilbert/gas-oauth2-gae
For that to work I added a project to PrimContact-user and created both a web-account and a
service account. Using aforementioned scripts as a starting point authentication works too, but
in the end it's not what I am trying to accomplish.
Client Account: the script is calling the api (contact-api) with an access token for the currently
logged in client although I provided the clientId of the PrimContact-user. Now I COULD run the script as PrimContact-user beforehand and store the token
in the document. If the access-token has not expired yet the other users can work with this
token just fine and therefore "operate" on the PrimContact-data. But as soon as the token
expires I would have to call the script as PrimContact-user again, which is not to very comfortable.
Service Account: got it working with gas-oauth2-gae, but the contact-list is empty. The call
itself is successfull though. I guess this is due to the service account not being tied to
the PrimContact-user although the project is associated with this user?
Goal:
Making an api-call (contacts) inside google-apps-script(spreadsheet) used by different users and
manipulate contact-data of a different account, i.e. the account who originally shared the spreadsheet.
Maybe I'm getting the whole idea of OAuth2 completely wrong, so far my understanding of the
clientAccount-thing is that the currently logged in user allows the project (which belongs to the
PrimContact-user) to manipulate the data of the currently logged in user.
What data the service-account-authenticated call is manipulating.. I'm not quite sure..
If it helps I can add the code-snippets, but as everythings "working" & still not doing what
I really need it to do I'm not sure if it's helpful.

Are there any hooks for user modification events in google apps?

Currently the bane of my existence is dealing with users email signatures at work, changing names, titles, departments, new users...it's all annoying. Currently I manage it with GAM and a semi templated HTML file to push changes, which works okay, but it's still a manual process. What I'm looking to do is create a small app script or app engine project that can...
detect a new or changed user
pull the fields needed to fill in their signature template
push the changes to their account
2 & 3 are no problem at all, it's #1 that I cannot find a reasonable solution to.
I had thought about using the google apps audit settings to email a specific mailbox when a new user is created, but that will only catch new users, not changes in titles and such. My only apparent option is something that runs periodically checking all the users signatures against what my script would generate and updating if needed, but that's hardly efficient and creates a potential timelapse in the waiting period meaning when people want things 'done now' (which is of course, every request), it will mean I manually trigger the job; effectively bringing me back to my original solution.
Is there any kind of user feed that contains changes available in google apps? Maybe google has a POST hook that hits a predefined URL on changes?
You can probably use push notifications for this https://developers.google.com/drive/web/push using the users.watch method https://developers.google.com/admin-sdk/directory/v1/reference/users/watch

Apps Script HTML Service Post request / sheet append limits

We have a chrome extension that posts data back to a Google Apps Script app and I'd like to know if I'm going to hit any limits at Google.
The Apps Script app has a doPost function that takes the information that was passed across and uses appendRow to add the content to different sheets. Very similar to how forms works but allows us to deploy to users (via the chrome extension) and have a better looking UI.
We're wanting to push this out to potentially thousands of users and we expect a few form submissions a day from each of them. Should I be expecting to hit any set limits with this?
I've already taken a look at https://script.google.com/a/netpremacy.com/dashboard but don't see anything that would indicate any limits.
Let me know if you need more info.
There are no published limits at this time. However, the key thing to ask with apps deployed as web apps is that is the App running as you (the developer) OR the users accessing the web app?
If its running as the users, then you are going to be ok with the volume. The quota is fully debited to the end user.
If its running as you, then you need to worry about other quota first - does it send out lots of emails, does it create a lot of documents, etc.
The only exception to quotas is ScritptDb that always consumes the script developers quota.