Is there any API to be notified that a user has delegated their calendar to my calendar? I would prefer an event I can subscribe to that would alert me that calendar their#account.com has delegated access to my#account.com
Is there any API to be notified that a user has delegated their calendar to my calendar?
No not directly in EWS you can subscribe to Folder level notifications https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/notification-subscriptions-mailbox-events-and-ews-in-exchange. However this will just tell you the folder has updated but not what on a folder has updated (eg in the case of delegation the permissions being changed etc.)
If you trying to capture Outlook Delegates (which is a different thing from somebody just going and assigning permissions to their calendar and or sharing externally) then because that also update the publicdelegate active directory property you can look at also event from Active Directory.
Also generally unless you have a real need for this to be realtime if you enable Mailbox auditing you will be able to also process this type of change by using the Audit logs. This method could also be used in conjunction with a notification to detect a certain type of change.
Related
Is it possible to create an add-on that can send off the contents of an email into a webservice? I see lots of documentation on add-ons interacting with external webservices and have been able to follow a simple demo about it, but there isn't much I can find about interacting with the emails itself.
I have an add-on in Outlook that grabs the email and sends it off to a webservice, but I want to replicate this in Gmail in some way.
Next, I would also like to know if it's possible to use a different web service based on the user. For example, if I were to deploy this same add-on for a coworker but they needed to send the email to the different service. Is there a configuration file somewhere that controls this?
Lastly, I was also interested in how Gmail add-ons store personalized information, as I feel like it would help clear things up. E.g. how the tasks add-on grabs the right ones for the currently logged in user and where they are stored.
I would be open to any other solutions to this issue.
Communicating with web service
You can use the UrlFetchApp class to connect to any target web service if it can be accessed via HTTP request. If you need to access different web services for different users, you can either do so via storing "user:url" property (see below) or by conditionally changing the URL according to effective user.
Determining the user
You can determine under whose authority the Add-on is running by using a Session class method getEffectiveUser() and getEmail() on the resulting user.
Storing personalized info
As for storing and fetching personalized information, there is a PropertiesService class you can use. Since you want to store info related to end users, you'll need to get a Properties class instance with access to user-specific properties via getUserProperties() method.
Useful links
Gmail Add-ons reference;
PropertiesService class reference;
Guide on PropertiesService usage;
UrlFetchApp class reference;
I'm looking to write an app that will use Google Calendar API's to remove a resource (e.g. a conference room) from an event, if it's discovered that the room does not end up being needed. Obviously the call to the API will be with administrative permissions, but we won't have access to individual user accounts to remove the resource from the event / invite.
Does anyone know of any way to use Google Calendar API's to update / alter the resources that are assigned to a meeting?
Thanks!
Rooms are added to events as attendees and a copy is created on their calendar. You will just need to find the right event and delete it from the room's calendar (using Calendar API). Administrative permissions should give you all the access you need.
You can also remove a Room from an event as the Room if you have the Room's authentication credentials. You use the Rooms credentials and the https://www.googleapis.com/calendar/v3/calendars/{calendarId}/events/{eventId} endpoint on the Room's primary calendar. This will not delete the event from the organizer's calendar.
Note: Regardless of the sendNotifications flag, Google will send a notification to the organizer when room delete/removes itself from an event (i.e. each time the endpoint is called). There is no workaround. If the organizer has all notifications turned off then they will not see these emails but it's still sent.
I think removing resources from an event can be done by using Google Apps Calendar Resource API. This API allows admin of the domain to add resources that users in the domain will be able to schedule on their calendars.
To delete a calendar resource, send a DELETE request to a resource ID's feed URL.
DELETE https://apps-apis.google.com/a/feeds/calendar/resource/2.0/{domain name}/{resourceId}
Is it possible to use a Google form, develop a GAS script that executes on form submission but have it run under the context of the users submitting the form?
Users will be in a GApps for Business domain?
Will it need to be published as a web app using doGet(), even though there will be no UI?
Only webApps have the ability to run under user's authority and they have an authorization request feature to handle that case. A form has no way to ask for authorization so it won't be able to do anything (or to trigger a script that would do anything) in the name of a user without explicit permission. That's a basic security case and hopefully there will be no way to go around it.
I guess the only way to get what you want would be to create the form with UiApp or HTML Service and deploy it as a webapp running under user's authority, in that case your users will be asked for authorization to access the services you need.
note : you said "even though there will be no UI?" but the form itself is a Ui isn't it ?...
I'm trying to set up a PC in kiosk mode that will display a list of events from a Google Calendar. I initially wanted to use the Google API for this (be it the JS client, Python client or other), but it seems that all of these require the user to consent via a page in the browser. This is not acceptable because it's a standalone system--there is no user to click on anything. The system will be on a daily power cycle so a 'consent once run forever' is also not possible.
Is there a way to use the authenticated (OAuth2.0) Google API to access calendar data without any user intervention whatsoever (except just a one-time initial setup)?
Thanks!
That's exactly what OAuth should be able to do. You should do a onetime setup (start he flow, authorize the request and get the tokens) and then store the tokens. Once the tokens are stored, you do NOT need any more user action as long as you have the tokens. The tokens would then be used to retrieve the data from the Google Calendar.
I've created a Google App Script that handle 2 different OAuth connections.
1- Google itself to send mail on behalf of the user and access google docs (google api console used to get keys, secret)
2- gtraxapp wich is a timesheet cloud-based app. (Script is registered, got a key/secret, etc.)
The script is published as a web app. It works perfectly for my user.
When logged on a different user name, I can authorize Google OAuth without providing different key/secret, and emails will be sent from the actual user.
Problem happens with the 2nd app (gTrax).
Authorization seems to work. Running the function inside the script to authorize lead to a screen asking for permission, gtrax then appears in the account as a registered app (could revoke access if needed).
But, when running the app, I get a message saying I need permission to do this action (UrlFetchApp / simple get)
My question is :
Is this possible that I need to register each user to get a key/secret for everyone (and dealing with that in the script)...
Or do OAuth can be registered with 1 key/secret ?
In other word, are (should) key/secret linked to a single user or are they only a kind of RSA-like key pairs that, when verified, can be used to authorize any user.
My understanding is this. When you use built-in Apps Script functions, like MailApp.sendEmail, the Google Apps Script "environment" takes care for you to ask authorization for the user (1st time he access your app) and save and manage the oAuth tokens for you, so it all runs smoothly.
When you call an external service using UrlFetchApp, Apps Script oAuth authorization process works differently. The authorization is just a strange popup you get on the script editor, when you actually make the fetch call. It is not processed at "compile time" and asked before you run anything like the other services. But you also do this step only once.
The "gotcha" is that this different authorization process does not work when a user is running the app as a webapp. AFAIK it only works from the script editor itself or running directly from a spreadsheet.
If your users are just a known few, you could advise everybody to open the script editor (or a spreadsheet that contains it) and run an specific function that will just attempt the UrlFetchApp.fetch call so the popup shows up and they authorize it. Once this step is done, they can use the webapp normally. Apps Script will do the magic for you after that.
But if you plan to share this broadly, say at the Chrome Web Store, and don't want to ask every user to do this somewhat strange step, then you'll need to manage all the authorization process yourself. It means, you'll have to register your app with the third party service (if it's Google's, it's at the API Console), where you will receive a client id and a client secret. With those you'll have to place a "Authorize" submit button on your app html that will redirect the users to the 3rd party authorization url, providing the correct scope, etc. When they authorize it, the 3rd party will redirect the user back to your app providing a code token as URL parameter. You'll use this code to call the 3rd party oAuth service to get the real access and possibly refresh tokens that you'll have to use on your UrlFetch calls. You'll be responsible to save these tokens, refresh them when they expire and so on. Not a very simple procedure :-/
Oh, and although your app have only one id and secret, the tokens are per user. Which makes sense, since each call you do must be on behalf of a specific user and he *must* have authorized it.
I hope this helps.