Posted by Saurabh Gupta, Product Manager, Google Apps Script
Back in December 2014, we announced the IFRAME sandbox mode for HtmlService which has helped improve the speed of an application’s user interface (UI). It also gives users a choice of using a variety of JS libraries on the client. We have been working hard to improve IFRAME sandbox mode and have added many features since then, including: Firefox support, file uploads, top navigation support, and improved Google Picker API support. Since IFRAME sandbox provides faster UIs and has more capabilities than NATIVE and EMULATED modes, developers should only be using IFRAME sandbox mode moving forward.
As of today, both EMULATED and NATIVE modes in HtmlService are deprecated. Over the next few months, we plan on sunsetting both EMULATED and NATIVE modes in stages to give you enough time to migrate your scripts.
We have created a migration guide to help you with this transition. For many scripts, no changes will be needed, unless they use a small set of features described in the migration guide. The guide also describes a few potential breaking changes. It is important that you review all your scripts that use HtmlService to ensure that the switch to IFRAME sandbox mode does not cause them to fail.
Here’s the timeline:
In November 2015, all new scripts will default to IFRAME sandbox mode unless NATIVE mode is explicitly specified. For example, if you make a copy of an existing script, the new script will use IFRAME sandbox mode unless you have explicitly set the sandbox mode to NATIVE.
In December 2015 (see sunset schedule for exact dates), EMULATED mode will be shutdown. Any scripts explicitly using EMULATED mode will default to IFRAME sandbox mode.
On April 28th, 2016, all scripts will default to IFRAME sandbox unless you have explicitly specified NATIVE mode in your script. For example, if your script has not specified any mode, then it will change from using NATIVE mode to IFRAME sandbox mode. Please make sure that your UI works well in IFRAME sandbox mode.
On June 30th 2016, NATIVE mode will be shutdown. All scripts explicitly using NATIVE mode will default to IFRAME sandbox mode.
While deprecations may at times seem inconvenient, this staged deprecation should ease in the migration process. Our goal is to provide a modern and secure environment enabling developers to create great apps for their users with Google Apps Script.
Originally posted on the Google Developer blog
Posted by Wesley Chun, Developer Advocate, Google Apps
Happy Monday! Have you ever been asked by your boss to do something simple (good) but long and tedious (bad)? Take for example, the simple task of counting up all of the YouTube views for your corporate videos and your competitors’. It doesn’t even have to be your boss. What if you and your gamer friends are competing to see whose gameplay clips are garnering the most attention? It’s easy to manually track ten videos, but how about 100 or even 1,000? While simple -- you can visit the YouTube to grab the view count for each video -- you know the real problem with a task like this is that you don’t scale with the amount of content, so it’s better to automate with a simple app instead. This is the exact scenario that my colleagues and I set out to address in the latest episode of the Launchpad Online, introducing users to a pair of Google developer tools that can help solve this particular problem:
The first developer tool covered is the YouTube Data API. You can access it like most modern Google APIs from your preferred programming environment using one of the Google APIs Client Libraries. However, this type of data generally lives in a spreadsheet, and if you’re using Google Sheets, you can instead write the app with Google Apps Script, a JavaScript environment running in Google’s cloud that, if authorized, can write that video information to the cells in your Sheet. YouTube is just one of the many supported services available to Apps Script developers.
As with all my Launchpad Online episodes, I walk you through a short code snippet (only eight lines this time) that will get you started building your own custom solution. If you’re new to the developer series, we share technical content aimed at novice Google developers… current tools with a little bit of code to help you launch your next app. Please give us your feedback below and tell us what topics you would like to see in future episodes!
Posted by Sushmit Goswami, Product Manager, Google Apps for Work and Wesley Chun, Developer Advocate, Google Apps
To provide developers and administrators with more fine-grained control, the Google Apps Admin SDK now includes new domain management features. These new APIs let you programmatically manage domains for your Google Apps account, similar to other RESTful resources like Users, Groups, etc., providing a superset of the domain management capabilities available on the Domains page in the admin console today.
The Customers API gives enterprise developers and administrators the ability to swap the current primary domain with a selected secondary domain for a Google Apps installation. The “change primary” operation is essentially transparent to the user, but users moved to the secondary domain will be subject to certain restrictions (refer to Help Center article for details). Customers who want to rebrand their business with a new primary domain can follow this up by renaming users from the old (now secondary) to the new (now primary) domain using the Users API.
The Domains API lets developers create tools for administrators to add and remove domains, similar to the functionality available on the Domains page in the admin console. In addition, the API lets you programmatically add aliases for any domain, primary or secondary, but aliases for secondary domain can only be added via the API.
Posted by Edward Jones, Software Engineer, Google Apps Script and Wesley Chun, Developer Advocate, Google Apps
Have you ever wanted a server API that modifies cells in a Google Sheet, to execute a Google Apps Script app from outside of Google Apps, or a way to use Apps Script as an API platform? Today, we’re excited to announce you can do all that and more with the Google Apps Script Execution API.
The Execution API allows developers to execute scripts from any client (browser, server, mobile, or any device). You provide the authorization, and the Execution API will run your script. If you’re new to Apps Script, it’s simply JavaScript code hosted in the cloud that can access authorized Google Apps data using the same technology that powers add-ons. The Execution API extends the ability to execute Apps Script code and unlocks the power of Docs, Sheets, Forms, and other supported services for developers.
One of our launch partners, Pear Deck, used the new API to create an interactive presentation tool that connects students to teachers by converting slide decks into interactive experiences. Their app calls the Execution API to automatically generate a Google Doc customized for each student, so everyone gets a personalized set of notes from the presentation. Without the use of Apps Script, their app would be limited to using PDFs and other static file types. Check out the video below to see how it works.
Bruce McPherson, a Google Developer Expert (GDE) for Google Apps, says: “The Execution API is a great tool for enabling what I call ‘incremental transition’ from Microsoft Office (and VBA) to Apps (and Apps Script). A mature Office workflow may involve a number of processes currently orchestrated by VBA, with data in various formats and locations. It can be a challenge to move an entire workload in one step, especially an automated process with many moving parts. This new capability enables the migration of data and process in manageable chunks.” You can find some of Bruce’s sample migration code using the Execution API here.
The Google Apps Script Execution API is live and ready for you to use today. To get started, check out the developer documentation and quickstarts. We invite you to show us what you build with the Execution API!
Posted by Muzammil Esmail, Product Manager, Google for Work
Google Apps users generate a lot of content at work—project plans, design documents, client presentations, and more. Many of these files are still relevant to an employee’s company or team even after he or she has left or transferred internally. The new Data Transfer API will make it easier for developers to build tools that will allow admins to better manage their end-user data, specifically apps that can transfer ownership of Google Docs, Sheets, and Slides, and all the other Google Drive files as well as Google+ pages in your Google for Work account—in bulk—from one employee/end-user to another using the API.
In July, we introduced the Data Transfer privilege, which makes it easier for admins to transfer data ownership. That same privilege is leveraged by the Data Transfer API. When enabled, it allows admins to programmatically migrate file ownership anytime they want using the API—provided they’ve enabled API access. In order to transfer ownership of Google Drive content as well as Google+ pages, super admins will need to grant/delegate the Data Transfer privilege to admins before end-user content can be migrated programmatically (via API or 3rd-party tools) or from the admin console.
This is what User Deletion looks like in the Administration console, but now you can also do this programmatically with the API.
To get started with the Data Transfer API, take a look at the developer documentation. Keep in mind that while this programmatic feature is new, admins can still transfer user data manually from the admin console. For more general information, see the Help Center pages on transferring file ownership on Google Drive and how to delete a user.
Originally posted on the Google Developers Blog.
Posted by Wesley Chun, Developer Advocate
Have you ever booked a dining reservation, plane ticket, hotel room, concert ticket, or seats to the game from your favorite app, only to have to exit that booking app to enter the details into your calendar? It doesn’t make for a friendly user experience. Why can’t today’s apps do that for you automatically?
In case you missed it the episode 97 of #GoogleDev100 the other week, I aim to inspire how app developers can streamline that process with the help of the Google Calendar API. A short Python script, anchored by the following snippet, is illustrated to show developers how easy it is to programmatically add calendar events:
CALENDAR = apiclient.discovery.build('calendar', 'v3', http=creds.authorize(Http())) GMT_OFF = '-07:00' # PDT/MST/GMT-7 EVENT = { 'summary': 'Dinner with friends', 'start': {'dateTime': '2015-09-18T19:00:00%s' % GMT_OFF}, 'end': {'dateTime': '2015-09-18T22:00:00%s' % GMT_OFF}, 'attendees': [ {'email': 'friend1@example.com'}, {'email': 'friend2@example.com'}, ], } CALENDAR.events().insert(calendarId='primary', body=EVENT).execute()
For deeper dive into the script, check out the corresponding blogpost. With code like that, your app can automatically insert your relevant events into your users’ calendars, saving them the effort of manually doing it themselves. One of the surprising aspects is that a limited set of actions, such as RSVPing, is even available to non-Google Calendar users. By the way, inserting events is just the beginning. Developers can also delete or update events instantly in case that upcoming dinner gets pushed back a few weeks. Events can even be repeated with a recurrence rule. Attachments are also supported so you can provide your users a PDF of the concert tickets they just booked. Those are just some of the things the API is capable of.
Ready to get started? Much more information, including code samples in Java, PHP, .NET, Android, iOS, and more, can be found in the Google Calendar API documentation. If you’re new to the Launchpad Online developer series, we share technical content aimed at novice Google developers… the latest tools and features with a little bit of code to help you launch that app. Please give us your feedback below and tell us what topics you would like to see in future episodes!
Posted by, Chris Han, Product Manager Google Apps Marketplace
The Google Apps Marketplace brings together hundreds of third-party applications that integrate with and enhance Google Apps for Work. It’s a great place to get discovered by more than five million Google Apps customers. Many of these customers depend on Google Apps Marketplace to find the solutions their organizations need, driving millions of users to the top listed apps.
Today, we’ve launched a brand new Google Apps Marketplace site aimed to improving discoverability and getting your app installed by even more customers. No need to do anything if you’ve already listed your app publicly on Google Apps Marketplace. Your app will appear on the new site automatically.
If you haven’t listed your app yet on Google Apps Marketplace, follow these instructions to get started!
Posted by Dan McGrath, Product Manager, Google Drive
Beginning August 31st, 2015, web hosting in Google Drive for users and developers will be deprecated. You can continue to use this feature for a period of one year until August 31st, 2016, when we will discontinue serving content via googledrive.com/host/[doc id].
In the time since we launched web hosting in Drive, a wide variety of public web content hosting services have emerged. After careful consideration, we have decided to discontinue this feature and focus on our core user experience.
For those who have used Drive to host websites, Google Domains can refer you to third parties for website hosting functionality.
For those who use this feature to serve non-user content to web and mobile applications, Google Cloud Platform offers a better-performing solution.
Editor's note: Posted by Romain Vialard, a Google Developer Expert and developer of Yet Another Mail Merge, a Google Sheets add-on.
Yet Another Mail Merge is a Google Sheets add-on that lets users send multiple personalized emails based on a template saved as a draft in Gmail and data in a Google Sheet. It can send hundreds of emails, but this kind of operation usually takes a few minutes to complete. This raises the question: what should be displayed in the user interface while a function is running on server side for a long time?
Firebase is all about real-time and became the answer to that issue. Last December, the Apps Script team announced a better version of the HtmlService with far fewer restrictions and the ability to use external JS libraries. With Firebase, we now had a solution to easily store and sync data in real-time.
Combined, users are able to know, in real-time, the number of emails sent by an Apps Script function running server-side. When the user starts the mail merge, it calls the Apps Script function that sends emails and connects to Firebase at the same time. Every time the Apps Script function has finished sending a new email, it increments a counter on Firebase and the UI is updated in real-time, as shown in the following image.
Inside the loop, each time an email is sent (i.e. each time we use the method GmailApp.sendEmail()), we use the Apps Script UrlFetch service to write into Firebase using its REST API. Firebase's capabilities makes this easy & secure and there’s no need for an OAuth Authorization Flow, just a Firebase app secret, as shown in the following example:
function addNewUserToFirebase() { var dbUrl = "https://test-apps-script.firebaseio.com"; var secret = PropertiesService.getScriptProperties().getProperty("fb-secret"); var path = "/users/"; var userData = { romainvialard:{ firstName:"Romain", lastName:"Vialard", registrationDate: new Date() } }; var params = { method: "PUT", payload : JSON.stringify(userData) } UrlFetchApp.fetch(dbUrl + path + ".json?auth=" + secret, params); }
On the client side, thanks to the improved Apps Script HtmlService, we can use the official JS client library to connect to Firebase and retrieve the data stored previously. Specifically, the on() method in this library can be used to listen for data changes at a particular location in our database. So each time a new task is completed on server side (e.g. new email sent), we notify Firebase and the UI is automatically updated accordingly.
var fb = new Firebase("https://test-apps-script.firebaseio.com"); var ref = fb.child('users/' + UID + '/nbOfEmailsSent'); ref.on("value", function(data) { if (data.val()) { document.getElementById("nbOfEmailsSent").innerHTML = data.val(); } });
In addition to the example above, there are other places where Firebase can be useful in Google Apps Script add-ons.
Those are just a few examples of what you can do with Apps Script and Firebase. Don’t hesitate to try it yourself or install Yet Another Mail Merge to see a live example. In addition, there is a public Apps Script library called FirebaseApp that can help you start with Firebase; use it like any other standard Apps Script library.
For example, you can easily fetch data from Firebase using specific query parameters:
function getFrenchContacts() { var firebaseUrl = "https://script-examples.firebaseio.com/"; var base = FirebaseApp.getDatabaseByUrl(firebaseUrl); var queryParameters = {orderBy:"country", equalTo: "France"}; var data = base.getData("", queryParameters); for(var i in data) { Logger.log(data[i].firstName + ' ' + data[i].lastName + ' - ' + data[i].country); } }
Build your own add-ons via Google Apps Script. Check out the documentation (developers.google.com/apps-script) to get more information as well as try out the Quickstart projects there. We look forward to seeing your add-ons soon!
Romain Vialard profile | website
Romain Vialard is a Google Developer Expert. After some years spent as a Google Apps consultant, he is now focused on products for Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.
Posted by Pepper Lebeck-Jobe, Classroom API Tech Lead
Classroom debuted last year to help teachers and students save time and collaborate with each other, and since then we’ve been working on how to make sure it worked well with other products that educators love and use in their classes.
Starting today, developers can embed the Classroom share button and sign up for the developer preview of the Classroom API. These tools make it easy for developers to seamlessly integrate with Classroom in ways that help teachers and students — like letting teachers create assignments directly from Quizlet, Duolingo, PBS and many other favorites.
By using the API, admins will be able to provision and populate classes on behalf of their teachers, set up tools to sync their Student Information Systems with Classroom, and get basic visibility into which classes are being taught in their domain. The Classroom API also allows other apps to integrate with Classroom.
Until the end of July, we’ll be running a developer preview, during which interested admins and developers can sign up for early access. When the preview ends, all Apps for Education domains will be able to use the API, unless the admin has restricted access.
A few developers have been helping us test the API, and we’re excited to share a few examples of what they’ve built:
Today we’re also introducing the Classroom share button, a simple way for developers – or schools – to allow teachers and students to seamlessly assign or turn-in links, videos and images from another webpage or product.
The share button only requires a few lines of JavaScript, and you can customize the button to meet the needs of your website. When teachers and students click the button, they can quickly share to Classroom without having to leave the site they’re on. More than 20 educational content and tool providers have already committed to integrating the Classroom share button, including:
To get started or learn more about either the API or integrating the share button, visit developers.google.com/classroom. And let us know what you’re building using the #withclassroom hashtag on Twitter or G+. As always, we’re looking forward to hearing your feedback and making sure that we’re addressing top needs. We’ll use the developer community site Stack Overflow to field technical questions and feedback about the Classroom API. Please use the tag google-classroom.
Posted by Iskander Akishev, Software Engineer, Google Calendar
The Google Calendar API allows you to create and modify events on Google Calendar. Starting today, you can use the API to also attach Google Drive files to Calendar events to make them—and your app—even more useful and integrated. With the API, you can easily attach meeting notes or add PDFs of booking confirmations to events.
Here's how you set it up:
1) Get the file information from Google Drive (e.g. via the Google Drive API):
GET https://www.googleapis.com/drive/v2/files { ... "items": [ { "kind": "drive#file", "id": "9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q, ... "alternateLink": "https://docs.google.com/presentation/d/9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q/edit?usp=drivesdk", "title": "Workout plan", "mimeType": "application/vnd.google-apps.presentation", ... }, ... ] }
2) Pass this information into an event modification operation using the Calendar API:
POST https://www.googleapis.com/calendar/v3/calendars/primary/events?supportsAttachments=true { "summary": "Workout", "start": { ... }, "end": { ... }, ... "attachments": [ { "fileUrl": "https://docs.google.com/presentation/d/9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q/edit?usp=drivesdk", "title": "Workout plan", "mimeType": "application/vnd.google-apps.presentation" }, ... ] }
Voilà!
You don’t need to do anything special in order to see the existing attachments - they are now always exposed as part of an event:
GET https://www.googleapis.com/calendar/v3/calendars/primary/events/ja58khmqndmulcongdge9uekm7 { "kind": "calendar#event", "id": "ja58khmqndmulcongdge9uekm7", "summary": "Workout", ... "attachments": [ { "fileUrl": "https://docs.google.com/presentation/d/9oNKwQI7dkW-xHJ3eRvTO6Cp92obxs1kJsZLFRGFMz9Q/edit?usp=drivesdk", "title": "Workout plan", "mimeType": "application/vnd.google-apps.presentation", "iconLink": "https://ssl.gstatic.com/docs/doclist/images/icon_11_presentation_list.png" }, ... ] }
Check out the guide and reference in the Google Calendar API documentation for additional details.
For any questions related to attachments or any other Calendar API features you can reach out to us on StackOverflow.com, using the tag #google-calendar.
Posted by Janet Traub, Program Manager, Google Apps APIs
The Google Apps Developer team recently hosted a 3-part Hangout On Air series that provided the developer community a unique opportunity to engage with the creative minds behind Google Apps developer tools. Each session covered topics ranging from business automation using Apps Script to Google Calendar API usage to creating Add-Ons for Docs & Sheets.
In the first installment of the series, Mike Harm, the creator of Apps Script and his colleague Kenzley Alphonse delivered a captivating session entitled, “Automate your Business with Apps Script.” Together, they reviewed the various features of Apps Script that can help developers build powerful solutions with Google Apps, such as simple scripts, to easily do a mail merge, export calendars into a Sheet, and to generate regularly scheduled reports.
The series then shifted focus to Google Calendar. In “Creating Calendar Events - Easy and Useful” Ali A. Rad (Product Manager) and Lucia Fedorova (Tech Lead) for Google Calendar API, explained how developers can benefit from injecting content into users’ calendars. In addition, they reviewed different approaches on Google Calendar to create events and meetings, such as API features, email markups, Android intents, Calendar import, and more.
We concluded the series with “How to Increase Traffic to Your Add-On with Google Apps Script.” This session, delivered by Apps Script Product Manager, Saurabh Gupta and Mike Harm, gave developers an in depth understanding of the Add-Ons framework, steps to deployment and strategies to increase adoption of their Docs, Sheets and Forms Add-Ons.
For more information on developing for Google Apps, visit developers.google.com/google-apps
If your app needs to keep up with changes in a Gmail mailbox, whether it's new mail being received or a label being added, you are likely familiar with periodically polling the Gmail API's history feed for updates. If you find this tedious, we have good news for you. Today, at Google I/O 2015, we're launching push notifications for the Gmail API.
Just subscribe to a Gmail mailbox and whenever a change occurs, the Gmail API will instantly notify your server using webhooks or another Cloud Pub/Sub API notification method. No polling required.
Check out the developers’ guide at https://developers.google.com/gmail/api/guides/push to get started. We can’t wait to see what you build.
Posted by Eric DeFriez, Gmail Extensibility Team. As a technical lead for Gmail APIs, Eric works to make it easy for developers to build on top of Gmail.
Posted by Saurabh Gupta, Product Manager
Originally posted to Google Developers blog
Back in 2014, we introduced add-ons for Google Docs, Sheets, and Forms in developer preview. Since then, the developer community has built a wide variety of features to help millions of Docs, Sheets and Forms users become more productive. Over the last few months, we launched a number of developer-friendly features that made it easier to build, test, deploy and distribute add-ons. Some key capabilities include:
With these features under our belt, we are ready to graduate add-ons out of developer preview. Starting today, any developer can publish an add-on. To ensure users find the best tools for them, every new add-on will undergo a review for adherence to our guidelines before it’s available in the add-ons store.
We can’t wait to see what you will build!
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.
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.
gapi.drive.realtime.debug();
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.
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.
AppsActivity.Activities.list()
drive.fileId
source
Update (2015-06-15): The sunset date listed below has been changed from June 26th to July 6th, 2015.
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:
OAuthConfig
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 July 6, 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.
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.
Protection
PageProtection
// 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); }
// 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(); } }
// 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); }
