Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite
The G Suite team recently launched the very first Google Slides API, opening up a whole new set of possibilities, including leveraging data already sitting in a spreadsheet or database, and programmatically generating slide decks or slide content based on that data. Why is this a big deal? One of the key advantages of slide decks is that they can take database or spreadsheet data and make it more presentable for human consumption. This is useful when the need arises to communicate the information reflected by that data to management or potential customers.
Walking developers through a short application demonstrating both the Sheets and Slides APIs to make this happen is the topic of today's DevByte video. The sample app starts by reading all the necessary data from the spreadsheet using the Sheets API. The Slides API takes over from there, creating new slides for the data, then populating those slides with the Sheets data.
Developers interact with Slides by sending API requests. Similar to the Google Sheets API, these requests come in the form of JSON payloads. You create an array like in the JavaScript pseudocode below featuring requests to create a cell table on a slide and import a chart from a Sheet:
requests
sheetID
chartID
slideID
presentations().batchUpdate()
SLIDES
Creating tables is fairly straightforward. Creating charts has some magical features, one of those being the linkingMode. A value of "LINKED" means that if the Sheet data changes (altering the chart in the Sheet), the same chart in a slide presentation can be refreshed to match the latest image, either by the API or in the Slides user interface! You can also request a plain old static image that doesn't change with the data by selecting a value of "NOT_LINKED_IMAGE" for linkingMode. More on this can be found in the documentation on creating charts, and check out the video where you'll see both those API requests in action.
linkingMode
For a detailed look at the complete code sample featured in the video, check out the deep dive post. We look forward to seeing the interesting integrations you build with the power of both APIs!
Formatting spreadsheets is accomplished by creating a set of request commands in the form of JSON payloads, and sending them to the API. Here is a sample JavaScript Object made up of an array of requests (only one this time) to bold the first row of the default Sheet automatically created for you (whose ID is 0):
{"requests": [ {"repeatCell": { "range": { "sheetId": 0, "startRowIndex": 0, "endRowIndex": 1 }, "cell": { "userEnteredFormat": { "textFormat": { "bold": true } } }, "fields": "userEnteredFormat.textFormat.bold" }} ]}
SHEETS.spreadsheets().batchUpdate(spreadsheetId=SHEET_ID, body=requests).execute()
For more details on the code in the video, check out the deepdive blog post. As you can probably guess, the key challenge is in constructing the JSON payload to send to API calls—the common operations samples can really help you with this. You can also check out our JavaScript codelab where we guide you through writing a Node.js app that manages customer orders for a toy company, featuring the toy orders data we looked at today but in a relational database. While the resulting equivalent Sheet is featured prominently in today's video, we will revisit it again in an upcoming episode showing you how to generate slides with spreadsheet data using the new Google Slides API, so stay tuned for that!
We hope all these resources help developers enhance their next app using G Suite APIs! Please subscribe to our channel and tell us what topics you would like to see in other episodes of the G Suite Dev Show!
// create new slide (title & body layout) { "createSlide": { "slideLayoutReference": { "predefinedLayout": "TITLE_AND_BODY" } } }, // insert text into textbox { "insertText": { "objectId": titleID, "text": "Hello World!" } }, // add bullets to text paragraphs { "createParagraphBullets": { "objectId": shapeID, "textRange": { "type": "ALL" } } }, // replace text "variables" with image { "replaceAllShapesWithImage": { "imageUrl": imageURL, "replaceMethod": "CENTER_INSIDE", "containsText": { "text": "{{COMPANY_LOGO}}" } } }
Posted by Tom Holman, Product Manager, Google Sheets
Originally posted to Google Cloud
When it comes to redefining how people go about their everyday work, Google and Salesforce have shared a remarkably similar path, with our roots planted firmly in the cloud.
That's why we were very excited to share the stage last week at Dreamforce to showcase two integrations that Salesforce built on top of G Suite: Salesforce Lightning for Gmail and Sales Cloud integration with Google Sheets. In addition to existing integrations with Google Calendar, Gmail (for Salesforce IQ), Drive and Contacts, these new offerings will go a long way in helping people work effectively with smarter tools.
At Dreamforce, we showcased the upcoming Lightning for Gmail integration, which brings together our leading CRM and email services.
With this integration, sales reps can now streamline repetitive but important tasks: they can review Salesforce records relevant to their emails, add contacts from their address book into Salesforce, and even create new Salesforce records, all from within Gmail.
A pilot of Lightning for Gmail will be available by the end of this year for free to all Salesforce customers. Interested customers can contact their Salesforce account managers to sign up for the pilot program.
The Sales Cloud integration with Sheets, meanwhile, makes it easy for sales reps to link any Salesforce List View to a Google Sheet. Users can also view, edit, and delete records within Sheets and sync those changes back to Salesforce. Better still, the integration also supports your business logic and validation rules.
We gave a joint preview of the Sales Cloud and Google Sheets integration at Google I/O this summer, and today are happy to announce that it will be available in beta to all Sales Cloud customers by the end of this year.
We had a blast working with the Salesforce team to bring these new solutions to life.
Posted by Michael Winser, Product Lead, Google Apps and Wesley Chun, Developer Advocate, Google Apps
Last week, we clarified the expectations and responsibilities when accessing Google user data via OAuth 2.0. Today, we’re announcing that in order to better protect users, we are increasing account security for enterprise Gmail users effective October 5, 2016. At this time, a new policy will take effect whereby users in a Google Apps domain, while changing their passwords on or after this date, will result in the revocation of the OAuth 2.0 tokens of apps that access their mailboxes using Gmail-based authorization scopes. Please note that users will not notice any specific changes on this date and their applications will continue to work. It is only when a user changes their password from that point moving forward that their Gmail-related tokens become invalid.
Developers should modify their applications to handle HTTP 400 or 401 error codes resulting from revoked tokens and prompt their users to go through the OAuth flow again to re-authorize those apps, such that they can access the user’s mailbox again (additional details below). Late last year, we announced a similar, planned change to our security policy that impacted a broader set of authorization scopes. We later decided not to move forward with that change for Apps customers and began working on a less impactful update as described above.
What is a revoked token?
A revoked OAuth 2.0 token no longer provides access to a user’s resources. Any attempt to use a revoked token in API calls will result in an error. Any existing token strings will no longer have any value and should be discarded. Applications accessing Google APIs should be modified to handle failed API calls.
Token revocation itself is not a new feature. Users have always been able to revoke access to applications in Security Checkup, and Google Apps admins have the ability to do the same in the Admin console. In addition, tokens that were not used for extended periods of time have always been subject to expiration or revocation. This change in our security policy will likely increase the rate of revoked tokens that applications see, since in some cases the process will now take place automatically.
What APIs and scopes are impacted?
To achieve the security benefits of this policy change with minimal admin confusion and end-user disruption, we’ve decided to limit its application to mail scopes only and to exclude Apps Script tokens. Apps installed via the Google Apps Marketplace are also not subject to the token revocation. Once this change is in effect, third-party mail apps like Apple Mail and Thunderbird―as well as other applications that use multiple scopes that include at least one mail scope―will stop accessing data upon password reset until a new OAuth 2.0 token has been granted. Your application will need to detect this scenario, notify the user that your application has lost access to their account data, and prompt them to go through the OAuth 2.0 flow again.
Mobile mail applications are also included in this policy change. For example, users who use the native mail application on iOS will have to re-authorize with their Google account credentials when their password has been changed. This new behavior for third-party mail apps on mobile aligns with the current behavior of the Gmail apps on iOS and Android, which also require re-authorization upon password reset.
How can I determine if my token was revoked?
Both short-lived access tokens and long-lived refresh tokens will be revoked when a user changes their password. Using a revoked access token to access an API or to generate a new access token will result in either HTTP 400 or 401 errors. If your application uses a library to access the API or handle the OAuth flow, then these errors will likely be thrown as exceptions. Consult the library’s documentation for information on how to catch these exceptions. NOTE: because HTTP 400 errors may be caused by a variety of reasons, expect the payload from a 400 due to a revoked token to be similar to the following:
{ "error_description": "Token has been revoked.", "error": "invalid_grant" }
How should my application handle revoked tokens?
This change emphasizes that token revocation should be considered a normal condition, not an error scenario. Your application should expect and detect the condition, and your UI should be optimized for restoring tokens.
To ensure that your application works correctly, we recommend doing the following:
If your application uses incremental authorization to accrue multiple scopes in the same token, you should track which features and scopes a given user has enabled. The end result is that if your app requested and obtained authorization for multiple scopes, and at least one of them is a mail scope, that token will be revoked, meaning you will need to prompt your user to re-authorize for all scopes originally granted.
Many applications use tokens to perform background or server-to-server API calls. Users expect this background activity to continue reliably. Since this policy change also affects those apps, this makes prompt notification requesting re-authorization even more important.
What is the timeline for this change?
To summarize, properly configured applications should be expected to handle invalid tokens in general, whether they be from expiration, non-existence, and revocation as normal conditions. We encourage developers to make any necessary changes to give their users the best experience possible. The policy change is planned to take effect on October 5, 2016.
Please see this Help Center article and FAQ for more details and the full list of mail scopes. Moving forward, any additional scopes to be added to the policy will be communicated in advance. We will provide those details as they become available.
Posted by William Denniss, Product Manager, Identity and Authentication Lavanya Mahendran, Policy Advisor, Google Cloud Platform and Google APIs
Developers have created an exciting ecosystem of mobile and web applications that offer a seemingly infinite array of features and services for consumers to utilize. Today you can download applications that offer to increase your productivity at work, as well as applications that manage your daily expenses or help you meditate, and many more.
We know that our users love using these applications, and we recognize that often Google users want to share their data with these applications to personalize or enhance the experience. Google provides a rich variety of API services that developers may access, and we provide developers the ability to request permission directly from our users when they want to access various categories of user data.
The privacy and security of our users’ data is very important to us, and we’ve always expected developers to treat Google user data with transparency and concern for user choice. Among other things, this means that we’ve long expected developers to get informed consent when they request access to user data, so that users understand what data they are sharing and how it will be used.
We’re always looking for ways to make our requirements more accessible to everyone, including our end-users. To that end, we recently published expanded policy guidelines for developers who wish to access Google user data using our API services. We hope this guidance will help developers and Google users interact in a manner that is informed and overall consistent with user expectations.
Read the full Google API Services User Data policy.
We hope that developers and Google users find this policy guidance helpful. We believe that transparency around the collection and use of Google user data is necessary to ensure informed user consent, but also that it genuinely fosters a helpful and productive dialogue between developers and users that ultimately benefits the entire ecosystem. Google account users can review and manage the apps and websites connected to their Google account from the My Account page.
Posted by Pierce Vollucci, Associate Product Manager, Gmail and Steve Bazyl, Developer Programs Engineer, Google Apps
When you send emails, your recipients might read them on a computer, tablet, or phone—or more likely, all three. However your message might look different on all these devices. Later this month, you’ll be able to use CSS media queries with Gmail and Inbox by Gmail to ensure that your message is formatted the way you intended, whether it's viewed on a computer, a phone in portrait mode, or a tablet in landscape mode. You’ll be able to change styles based on width, rotation, and resolution, allowing for more responsive formatting to optimize your email for every device.
In discussions with email designers, these supported CSS rules were identified as the most useful media queries to support responsive design. This is just one part of an overall effort to expand CSS support in Gmail and to give email designers more control over how their messages are rendered. For example, the CSS below applies the color red when the screen width exceeds 500px.
@media screen and (min-width: 500px) { .colored { color:red; } }
You can find the full list of supported CSS rules in the developer documentation. We hope this reference helps you create more feature-rich, responsive email for users. Happy formatting!
