Author Archives: Google Apps Developer Blog Editor

Introducing New Post Install Notification and Experience for Google Apps Marketplace

Posted by Chris Han, Product Manager, Google Apps Marketplace team

Today we’re announcing two changes to the post install experience for Google Apps Marketplace. Both changes are geared towards improving end user awareness and active usage of your apps.

First, after installing a Marketplace app, admins will be given the opportunity to send a notification to end users. This enables admins to easily tell users that your app is now available, and how to access it.

The notification will only appear to the users in the Organizational Unit (OU) or domain for which the admin has installed the app. The notification will appear in each user’s Notification Center and will describe how to access and launch the app.


Second, we’ve completely changed the post install experience itself, making instructions for accessing your app clearer. During the post install experience, we now show how to access all the extension points of your app (e.g. Apps launcher, Drive, Add-ons to Docs, Sheets, and Forms).


For more information on this feature, please see the Help Center article.

The Realtime API: In memory mode, debug tools, and more

Posted by Cheryl Simon Retzlaff, Software Engineer on the Realtime API team

Real-time collaboration is a powerful feature for getting work done inside Google docs. We extended that functionality with the Realtime API to enable you to create Google-docs style collaborative applications with minimal effort.

Integration of the API becomes even easier with a new in memory mode, which allows you to manipulate a Realtime document using the standard API without being connected to our servers. No user login or authorization is required. This is great for building applications where Google login is optional, writing tests for your app, or experimenting with the API before configuring auth.

The Realtime debug console lets you view, edit and debug a Realtime model. To launch the debugger, simply execute gapi.drive.realtime.debug(); in the JavaScript console in Chrome.



Finally, we have refreshed the developer guides to make it easier for you to learn about the API as a new or advanced user. Check them out at https://developers.google.com/drive/realtime.

For details on these and other recent features, see the release note.

New Advanced services in Apps Script

Posted by Kalyan Reddy, Developer Programs Engineer

Apps Script includes many built-in Google services for major products like Gmail and Drive, and lately, we've been working to add other APIs that developers have been clamoring for as advanced Google services. Today, we are launching seven more advanced services, including:

Like all other advanced services in Apps Script, they must first be enabled before use. Once enabled, they are just as easy to use as built-in Apps Script services -- the editor provides autocomplete, and the authentication flow is handled automatically.

Here is a sample using the Apps Activity advanced service that shows how to get a list of users that have performed an action on a particular Google Drive file.


function getUsersActivity() {
  var fileId = 'YOUR_FILE_ID_HERE';
  var pageToken;
  var users = {};
  do {
    var result = AppsActivity.Activities.list({
      'drive.fileId': fileId,
      'source': 'drive.google.com',
      'pageToken': pageToken
    });
    var activities = result.activities;
    for (var i = 0; i < activities.length; i++) {
      var events = activities[i].singleEvents;
      for (var j = 0; j < events.length; j++) {
        var event = events[j];
        users[event.user.name] = true;
      }
    }
    pageToken = result.nextPageToken;
  } while (pageToken);
  Logger.log(Object.keys(users));
}

This function uses the AppsActivity.Activities.list() method, passing in the required parameters drive.fileId and source, and uses page tokens to get the full list of activities. The full list of parameters this method accepts can be found in the Apps Activity API's reference documentation.

Publishing Google Docs add-ons for domain-wide installation

Cross-posted from the Google Developers Blog

Since we introduced add-ons for Google Docs, Sheets, and Forms last year, our developer partners have brought a world of new features to millions of users. Still, administrators for Google Apps domains (and developers!) kept asking for two things:


So, if you’ve built (or are thinking of building) a Google Docs, Sheets or Forms add-on, then be sure to make your add-on available in Google Apps Marketplace today.

Posted by Saurabh Gupta, product manager, Google Apps Script

Changes to OAuth in Apps Script

Posted by Eric Koleda, Developer Platform Engineer

OAuth is the de facto standard for authorization today and is used by most modern APIs. Apps Script handles the OAuth flow automatically for dozens of built-in and advanced services, but until recently only had limited support for connecting to other OAuth-protected APIs such as Twitter, etc. The URL Fetch service’s OAuthConfig class only works with the older OAuth 1.0 standard and only allows the developer of the script (not its users) to grant access to their data. To address this, we’ve create two new open source libraries:

With only a few clicks, you can add these libraries to your scripts. The full source code is available on GitHub if you need to tinker with how they work. These libraries allow for greater control over the OAuth flow, including the ability for users to grant access separately, a long standing feature request from the community.

We believe that these open libraries are a better alternative to our previous solution, and therefore we are deprecating the OAuthConfig class. The class will continue to function until June 26, 2015, after which it will be removed completely and any scripts that use it will stop working We’ve prepared a migration guide that walks you through the process of upgrading your existing scripts to use these new libraries.

Separate from these changes in Apps Script and as announced in 2012, all Google APIs will stop supporting OAuth 1.0 for inbound requests on April 20, 2015. If you use OAuthConfig to connect to Google APIs, you will need to migrate before that date. Update your code to use the OAuth2 library or the API’s equivalent Advanced Service if one exists.


OAuthConfig Connecting ToMigrate ToMigration Deadline
Google API (Calendar, Drive, etc)OAuth2 for Apps Script or Advanced ServiceApril 20, 2015
Non-Google API (Twitter, etc)OAuth1 for Apps ScriptJune 26, 2015

We see Apps Script and Sheets as the perfect hub for connecting together data inside and outside of Google, and hope this additional OAuth functionality makes it an even more compelling platform.

Control protected ranges and sheets in Google Sheets with Apps Script

A few weeks ago, the Google Sheets team introduced improved control over protected sheets and ranges. Developers have told us they're looking for the same power in Google Apps Script — after all, ever since we added data validation to the Spreadsheet service, programmatic control over protected ranges has been the most popular request on the Apps Script issue tracker.

Today, we are excited to give you that granular control.

With the new Protection class in the Spreadsheet service, your scripts can touch every aspect of range or sheet protection, just like in the new UI. (The older PageProtection class, which had more limited features, will be deprecated, but will stick around in case you need to work with older spreadsheets. The new Protection class only applies to the newer version of Sheets.)

Code samples


So let's see the new stuff in action. Let's say you want to prohibit anyone other than yourself from editing cells A1:B10:

// Protect range A1:B10, then remove all other users from the list of editors.
var ss = SpreadsheetApp.getActive();
var range = ss.getRange('A1:B10');
var protection = range.protect().setDescription('Sample protected range');

// Ensure the current user is an editor before removing others. Otherwise, if the user's edit
// permission comes from a group, the script will throw an exception upon removing the group.
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
  protection.setDomainEdit(false);
}

Or maybe you want to remove all range protections in the whole spreadsheet:

// Remove all range protections in the spreadsheet that the user has permission to edit.
var ss = SpreadsheetApp.getActive();
var protections = ss.getProtections(SpreadsheetApp.ProtectionType.RANGE);
for (var i = 0; i < protections.length; i++) {
  var protection = protections[i];
  if (protection.canEdit()) {
    protection.remove();
  }
}

Or perhaps you want to protect an entire sheet, but carve out a small hole in it — an unprotected range within a protected sheet — that others can still edit:

// Protect the active sheet except B2:C5, then remove all other users from the list of editors.
var sheet = SpreadsheetApp.getActiveSheet();
var protection = sheet.protect().setDescription('Sample protected sheet');
var unprotected = sheet.getRange('B2:C5');
protection.setUnprotectedRanges([unprotected]);

// Ensure the current user is an editor before removing others. Otherwise, if the user's edit
// permission comes from a group, the script will throw an exception upon removing the group.
var me = Session.getEffectiveUser();
protection.addEditor(me);
protection.removeEditors(protection.getEditors());
if (protection.canDomainEdit()) {
  protection.setDomainEdit(false);
}

Bam! Easy. Hope you find this useful, and happy scripting!

Posted by Sam Berlin, engineer, Google Sheets

Retiring the Email Migration API

Posted by Wesley Chun, Developer Advocate, Google Apps

Last summer, we launched the new Gmail API, giving developers more flexible, powerful, and higher-level access to programmatic email management, not to mention improved performance. Since then, it has been expanded to replace the Google Apps Admin SDK's Email Migration API (EMAPI v2). Going forward, we recommend developers integrate with the Gmail API.

EMAPI v2 will be turned down on November 1, 2015, so you should switch to the Gmail API soon. To aid you with this effort, we've put together a developer’s guide to help you migrate from EMAPI v2 to the Gmail API. Before you do that, here’s your final reminder to not forget about these deprecations including EMAPI v1, which are coming even sooner (April 20, 2015).

Reminder to migrate to updated Google Data APIs

Over the past few years, we’ve been updating our APIs with new versions across Drive and Calendar, as well as those used for managing Google Apps for Work domains. These new APIs offered developers several improvements over older versions of the API. With each of these introductions, we also announced the deprecation of a set of corresponding APIs.

The deprecation period for these APIs is coming to an end. As of April 20, 2015, we will discontinue these deprecated APIs. Calls to these APIs and any features in your application that depend on them will not work after April 20th.

Discontinued APIReplacement API
Documents List APIDrive API
Admin AuditAdmin SDK Reports API
Google Apps ProfilesAdmin SDK Directory API
ProvisioningAdmin SDK Directory API
ReportingAdmin SDK Reports API
Email Migration API v1Email Migration API v2
Reporting VisualizationNo replacement available

When updating, we also recommend that you use the opportunity to switch to OAuth2 for authorization. Older protocols, such as ClientLogin, AuthSub, and OpenID 2.0, have also been deprecated and are scheduled to shut down.

For help on migration, consult the documentation for the APIs or ask questions about the Drive API or Admin SDK on StackOverflow.

Posted by Steven Bazyl, Developer Advocate

Speeding up HtmlService in Apps Script

Apps Script's HTML service is a great way to easily build user interfaces for Docs, Sheets, and Forms add-ons. However, HTML service is S-L-O-W. And until today there have been quite a few restrictions on using HTML service, including the inability to use a variety of JavaScript libraries.

Today, we are introducing an update to HTML service — IFRAME sandbox mode. Using this sandbox mode, you can significantly improve the performance. There are three key benefits.
  1. Your UI loads up much faster
  2. Standard HTML, JavaScript, and CSS features are now available without any restrictions
  3. It requires very few code changes: just set the SandboxMode to IFRAME:
var html = HtmlService.createHtmlOutputFromFile('foo');
html.setSandboxMode(HtmlService.SandboxMode.IFRAME);

We couldn’t resist using the new HTML service ourselves, so we’ve published an alternate version of the Google Translate add-on on GitHub that uses the iframe sandbox mode as well as Polymer and material design concepts.

translate-sample.png
With the launch of the IFRAME sandbox, it is now time to bid goodbye to UiApp. The UI service was a very useful way to serve user interfaces in Docs and Sheets at a time when sandboxing technologies were still evolving. Effective today, UI service is deprecated. It will be removed from documentation and autocomplete in the script editor on June 30, 2015. If you have built any UIs using UiApp, they will continue to work.

We are also deprecating the DocsList service. The Drive service and advanced Drive service are more powerful ways to access Google Drive data from Apps Script. DocsList will be shut down on April 20, 2015. Please migrate your scripts from the DocsList service to the Drive service or the advanced Drive service.

We understand that feature deprecation is sometimes inconvenient, but we strongly believe that the new features help the product evolve and gives Apps Script users better functionality, ultimately allowing developers to create more powerful solutions.


Posted by Saurabh Gupta, Product Manager, Google Apps Script

Get your Google Drive App listed on the Google Apps Marketplace

The Google Apps Marketplace brings together hundreds of third-party applications that integrate and enhance Google Drive, part of Google Apps for Work, our suite of collaboration and productivity tools for businesses. To improve discoverability and increase adoption, it’s important to make your Google Drive app integration available on the marketplace.

Today, we want to share with you four easy steps to get listed immediately and enable admins to install your application for all users in their domain. For more details, check out the Google Apps Marketplace documentation.

Step 1: Open your Drive project on Google Cloud console. Turn on “Google Apps Marketplace SDK” for your project. Screen Shot 2014-08-20 at 11.50.10 PM.png

Step 2: Click the gear icon to configure “Google Apps Marketplace SDK”. Refer to Google Apps Marketplace documentation for details. In the scopes section, be sure to request the same scopes as your Google Drive application, and check the “Enable Drive extension” checkbox.

Step 3: Go to the Chrome Web Store developer console and select your published Drive application.

Step 4: Update the following line in your Drive application’s Chrome Web Store manifest, upload and publish.

"container":"GOOGLE_DRIVE"
with
“container”: [”GOOGLE_DRIVE”, ”DOMAIN_INSTALLABLE”]

You’re done! You application is now available to all Google Apps for Work customers to install on a domain-wide basis through the Google Apps Marketplace. Refer to Publishing your app documentation for details. You can access Google Apps Marketplace inside Google Admin Console and verify your newly listed application.

Please subscribe to the Google Apps Marketplace G+ community for the latest updates.
Posted by Hiranmoy Saha, Software Engine, Google Apps Marketplace