Tag Archives: Google Apps

Introducing Team Drives for developers

Originally posted by Hodie Meyers, Product Manager, Google Drive, and Wesley Chun (@wescpy), Developer Advocate, G Suite on the G Suite Developers Blog

Enterprises are always looking for ways to operate more efficiently, and equipping developers with the right tools can make a difference. We launched Team Drives this year to bring the best of what users love about Drive to enterprise teams. We also updated the Google Drive API, so that developers can leverage Team Drives in the apps they build.

In this latest G Suite Dev Show video, we cover how you can leverage the functionality of Team Drives in your apps. The good news is you don't have to learn a completely new API—Team Drives features are built into the Drive API so you can build on what you already know. Check it out:

By the end of this video, you'll be familiar with four basic operations to help you build Team Drives functionality right into your apps:

  1. How to create Team Drives
  2. How to add members/users to your Team Drives
  3. How to create folders in Team Drives (just like creating a regular Drive folder)
  4. How to upload/import files to Team Drives folders (just like uploading files to regular folders)

Want to explore the code further? Check out the deep dive blog post. In all, the Drive API can help a variety of developers create solutions that work with both Google Drive and Team Drives. Whether you're an Independent Software Vendor (ISV), System Integrator (SI) or work in IT, there are many ways to use the Drive API to enhance productivity, help your company migrate to G Suite, or build tools to automate workflows.

Team Drives features are available in both Drive API v2 and v3, and more details can be found in the Drive API documentation. We look forward to seeing what you build with Team Drives!

From the courtly fashions of Versailles to the unmatched elegance of the Saree: 3000 years of fashion brought to you in a new, immersive way


What we wear tells a lot about our social identity, our customs, our habits and where we come from. It's appropriate to say that we don’t just wear clothes – we wear our culture!

Highlighting this very aspect, we at Google Arts & Culture have launched an exciting new project “We wear culture” that showcases 3000 years of fashion from across 42 countries in partnership with 183 world famous museums, fashion councils and universities. Using state of the art technology, including Virtual Reality, 360º videos and Gigapixel images, the platform enables unique online access to historic and contemporary stories that decode the various aspects of fashion for everyone. The stories, photos, videos and VR experiences will appeal to all those who are curious about its various intersections with music, pop culture, dance, technology,  economics and so much more.

So if you want to know more about the ancient Silk Road, or the courtly fashions of Versailles, to how the Vivienne Westwood Corset came to be reconceived as a symbol for sexual empowerment, or the origin of the British punk or the stories behind the clothes you wear today, it’s all there at g.co/wewearculture. Perhaps you’re looking for more? You can explore even the Iconic pieces that changed the way generations dressed, be it Marilyn Monroe’s famous Ruby Slipper by Salvatore Ferragamo or the Black Dress by Chanel. It’s there for you to explore,  at your fingertips and at your leisure.

           



Vivienne Westwood Corset courtesy Victoria & Albert Museum; Ruby Slipper of Marilyn Monroe courtesy Museo Salvatore Ferragamo

The Richness and diversity of Indian Fashion has always been marked by its distinctive and varied craftsmanship, it’s fabrics, the weaves, the natural dyes and vibrant colours as well as the classic Indian drape - the iconic Indian Saree. It would be apt to say that the most versatile garment in the world, the saree, is referenced the world over and worn by millions of women on a daily basis.

To celebrate the rich history of this iconic nine yards, Border & Fall in The Sari Project  have explored 60 regional draping styles. You can also view in detail the varied weaves from across India, from Gharchola to  Patola to Temple to Ikat sarees or trace the story and importance of Indian textiles from ancient sculptures, to heirloom textiles and how events such as Gandhi’s Khadi Movement influenced the craftsmanship from Chhatrapati Shivaji Maharaj Vastu Sangrahalaya (CSMVS). Available online from the CSMVS collection are the heirloom sarees of the Tagore family and that of Homi J. Bhabha’s family.
Various sari drapes courtesy Border&Fall

Of the people, of the land. There is plenty of regional textile and fashion heritage to be discovered. You can revisit the colonial Indian fashion with Dr. Bhau Daji Lad Mumbai City Museum, and trace the story of the history and impact of cotton in early trade of textiles. Then there are the designs from north-eastern India including the weaves of tribes such as the Nagas, Meitis and the traditional attire from Meghalaya called ‘Dhara’ or ‘Nara’ worn by the Khasi women during special occasions, made up of costly Mulberry and Eri silk yarn.  From down south, view Salar Jung Museum’s exhibits capturing the dress and fashion of royal attires of the Nizams from 19th century Hyderabad (part of Deccan region). Revisit the art of Brocades, Patola and Baluchari with a special exhibit by Museum of Art and Photography.





Navjote ceremony coat of Cursetjee Vakil courtesy CSMVS; Ethnographic documentation of drape styles courtesy CSMVS; Salar Jung III in a sherwani courtesy Salar Jung Museum

The SEWA Hansiba Museum in Randhapur is completely owned and managed by rural women artisans. The museum contains heirlooms by the local communities, such as the Ahir, Rabari and Harijan. The local skilling has helped bond stronger communities, and top fashion designers are now approaching them for fashion sampling. Flamboyant stitches to regional exchanges, the women are building economic security for themselves.


If it is colour that catches your interest, then explore how Indigo cultivation dates back to the Indus Valley civilisation and how this natural dye has been often credited with opening up an extensive range of beautiful blue shades that redefined global fashion even as the knowledge of extracting blue color from green leaves of indigo was closely guarded within the families.  You don’t have to stop at Indigo or India, you can explore the colour palette of global fashion over the years.

With over over 400 online exhibitions and stories sharing a total of 30.000 photos, videos and other documents;  4 virtual reality experiences of iconic fashion pieces; over 700 ultra high-resolution gigapixel images and over 40 venues offer backstage access on Google Street View you could easily get lost in fashion!

We could not have done this it without our partners around the globe. In India we are very proud to partner with Chhatrapati Shivaji Maharaj Vastu Sangrahalaya (CSMVS), Dr. Bhau Daji Lad Mumbai City Museum (BDL), SEWA Hansiba Museum, Salar Jung Museum, Indian Museum Kolkata, Museum of Art & Photography, Craft Revival Trust, Avani Society, Worldview Impact Foundation, Border & Fall to celebrate this rich history of Indian fashion and bring to life the creativity, heritage and craftsmanship -- for anyone around the world to see, learn, experience and cherish. The new online exhibition opens today at g.co/wewearculture online for free and will also be available through the Google Arts & Culture mobile app both on iOS and Android.

Posted by Simon Rein, India Programme Manager, Google Arts & Culture


VIDEO: Part 1—Introducing Team Drives for developers



Enterprises are always looking for ways to operate more efficiently, and equipping developers with the right tools can make a difference. We launched Team Drives this year to bring the best of what users love about Drive to enterprise teams. We also updated the Google Drive API, so that developers can leverage Team Drives in the apps they build.

In this latest G Suite Dev Show video, we cover how you can leverage the functionality of Team Drives in your apps. The good news is you don’t have to learn a completely new API—Team Drives features are built into the Drive API so you can build on what you already know. Check it out:

By the end of this video, you‘ll be familiar with four basic operations to help you build Team Drives functionality right in your apps:
  1. How to create Team Drives 
  2. How to add members/users to your Team Drives 
  3. How to create folders in Team Drives (just like creating a regular Drive folder) 
  4. How to upload/import files to Team Drives folders (just like uploading files to regular folders) 
The Drive API can help a variety of developers create solutions that work with both Google Drive and Team Drives. Whether you’re an Independent Software Vendor (ISV), System Integrator (SI) or work in IT, there are many ways to use the Drive API to enhance productivity, help your company migrate to G Suite, or build tools to automate workflows.

Team Drives features are available in both Drive API v2 and v3, and more details can be found in the Drive API documentation. We look forward to seeing what you build with Team Drives!

Google I/O session recap: how to build custom apps with App Maker



Every company has workflows and processes that are unique to its business, customers and employees. Often, these are captured manually within large spreadsheets or ad-hoc databases with macros and scripts. But what if they could be turned into custom business apps instead? Apps that provide useful UIs and distinct user roles, while helping to minimize data entry errors and increase productivity?

This year at Google I/O, I shared reasons why businesses should use App Maker—our low-code, application development tool that lets companies quickly build custom apps in G Suite. Check it out here:


And for those who’d like more detail, here is a recap of my presentation.

Closing enterprise “app gaps” with App Maker 

“App gaps” are a reality for most companies, even those that embrace major SaaS products. Think about the edge cases that aren’t addressed with a standard CRM offering like conducting territory planning or tracking asset performance.

We experienced similar gaps at Google. A few years ago, our HR recruiters were overwhelmed with the thousands of monthly interviews that each generated lengthy feedback reports from multiple interviewers. This volume made it difficult for hiring committees to calibrate candidates and make timely decisions, and resulted in delayed responses. To fix this, our IT team decided to build an app by cobbling elements from our own infrastructure.

Over time, more app requests came in from other parts of Google, so we created App Maker. What started as a handful of apps within Google, evolved into nearly 400 internal apps used by thousands. Plus, the majority of these apps were built by non-engineers outside of IT.

Today, App Maker gives software engineers and citizen developers—like business analysts or coding enthusiasts—the ability to quickly build and deploy apps to get around their workflow challenges.

How does it work? 

App Maker makes it easy to build apps in days, not months, because of its easy data-binding and drag-and-drop UI design. You can also integrate your apps with various data sources, Google services or APIs to cover broad legacy assets. Any app you create is also a part of Drive in G Suite so your data never leaves your domain.

Here’s how to build an App Maker app in three steps:
  1. Define your data models, by importing existing Google Sheets to App Maker, connecting to Google Cloud SQL instances, or manually defining custom objects field by field.
  2. Build your UI by adding pre-built components like data entry forms, report templates and easily create event triggers and application flows. 
  3. Optionally, add open source HTML, CSS and JavaScript to run on the client UI and on the app server, implementing custom functionality that’s not provided out-of-the-box.
App Maker is currently in Early Adopter Program (EAP) for every G Suite Business customer. To get started, apply here.

Ideas to get started 

By now you’re probably wondering what you can build. Well, based on our customers’ experience, here are some good starting points:
  • If you have a large Sheet with more than a handful of users updating it regularly: Sheets usually have an underlying workflow. An App Maker app will provide a better UI for it—showing the workflow visually, prompting for actions and eliminating data entry errors. 
  • If you perform recurring bulk operations in Calendar or Gmail: Say an employee joins or leaves a department, you can build an App Maker app to generate the appropriate bulk-operations in a few clicks. 
  • If your company is already using Apps Script and BigQuery: This means you’ve already invested in customizing workflows. App Maker can increase the velocity of developing custom apps.
Go build your apps with App Maker in G Suite—sign up for the EAP today.

Updating developer identity guidelines and registration processes to protect users




Last week, we took immediate action to protect users from a phishing attack that attempted to abuse the OAuth authorization infrastructure.

Today, we’re supplementing those efforts to help prevent these types of issues in the future. These changes may add some friction and require more time before you are able to publish your web application, so we recommend that you plan your work accordingly.

Updating app identity guidelines 

As our Google API user data policy states, apps must not mislead users. For example, app names should be unique to your application and should not copy others'.

To further enforce this policy, we are updating our app publishing process, our risk assessment systems, and our user-facing consent page in order to better detect spoofed or misleading application identities. You may see an error message as you’re registering new applications or modifying existing application attributes in the Google API Console, Firebase Console, or Apps Script editor as a result of this change.

New review processes and restrictions on web apps requesting user data 

We have also enhanced our risk assessment for new web applications that request user data.

Based on this risk assessment, some web applications will require a manual review. Until the review is complete, users will not be able to approve the data permissions, and we will display an error message instead of the permissions consent page. You can request a review during the testing phase in order to open the app to the public. We will try to process those reviews in 3-7 business days. In the future, we will enable review requests during the registration phase as well.

You can continue to use your app for testing purposes before it is approved by logging in with an account registered as an owner/editor of that project in the Google API Console. This will enable you to add additional testers, as well as initiate the review process.

We also recommend developers review our earlier post outlining their responsibilities when requesting access to user data from their applications. Our teams will continue our constant efforts to support a powerful, useful developer ecosystem that keeps users and their data safe.

Create quizzes in Google Forms with Apps Script



Last year, we launched Quizzes in Google Forms to help teachers and students take assessment to scale. Using Quizzes, teachers are able to automate testing and give feedback to students faster by having Forms check responses against correct answers automatically. Today, we are making that functionality available to developers by extending the Google Apps Script Forms Service. With this feature, you can create and customize quizzes programmatically with Apps Script.

More specifically:
  • Create quizzes 
  • Assign point values and correct answers for questions 
  • Implement custom grading schemes 
Let’s take a look at an example use case and relevant code snippet.

Creating an auto-graded question 

Multiple choice, checkbox and dropdown questions can be auto-graded, which means students can see their grades immediately upon submission. This is done by designating which options are the correct answer. Teachers can also set automatic feedback to show correct or incorrect responses, as well as assign point values to the question.

Here is the Apps Script code that lets you create the quiz above:
function createGradedCheckboxQuestionWithAutofeedback() {
// Make sure the form is a quiz.
var form = FormApp.getActiveForm();
form.setIsQuiz(true);

// Make a 10 point question and set feedback on it
var item = FormApp.getActiveForm().addCheckboxItem();
item.setTitle("What flavors are in neapolitan ice cream?");
item.setPoints(10);
// chocolate, vanilla, and strawberry are the correct answers
item.setChoices([
item.createChoice("chocolate", true),
item.createChoice("vanilla", true),
item.createChoice("rum raisin", false),
item.createChoice("strawberry", true),
item.createChoice("mint", false)
]);
// If the respondent answers correctly, they'll see this feedback when they view
//scores.
var correctFeedback = FormApp.createFeedback()
.setText("You're an ice cream expert!")
.build();
item.setFeedbackForCorrect(correctFeedback);

// If they respond incorrectly, they'll see this feedback with helpful links to
//read more about ice cream.
var incorrectFeedback = FormApp.createFeedback()
.setText("Sorry, wrong answer")
.addLink(
"https://en.wikipedia.org/wiki/Neapolitan_ice_cream",
"Read more")
.build();
item.setFeedbackForIncorrect(incorrectFeedback);
}
For more details on what you can build with the Apps Script Forms Service, review the documentation, ask questions on Stack Overflow or in the G+ community, and let us know what else you’d like to see using the new public issue tracker for Apps Script.

Using field masks with update requests to Google APIs

Originally posted on the G Suite Developers Blog
Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

We recently demonstrated how to use field masks to limit the amount of data that comes back via response payloads from read (GET) calls to Google APIs. Today, we'll focus on a different use case for field masks: update requests.

In this scenario, field masks serve a different, but similar purpose—they still filter, but function more like bitmasks by controlling which API fields to update. The following video walks through several examples of update field mask usage with both the Google Sheets and Slides APIs. Check it out.


In the sample JSON payload below, note the request to set the cells’ bold attribute to true (per the cell directive below), then notice that the field mask (fields) practically mirrors the request:

{
"repeatCell": {
"range": {
"endRowIndex": 1
},
"cell": {
"userEnteredFormat": {
"textFormat": {
"bold": true
}
}
},
"fields": "userEnteredFormat/textFormat/bold",
}
}

Now, you might think, "is that redundant?" Above, we highlighted that it takes two parts: 1) the request provides the data for the desired changes, and 2) the field mask states what should be updated, such as the userEnteredFormat/textFormat/bold attribute for all the cells in the first row. To more clearly illustrate this, let's add something else to the mask like italics so that it has both bold and italic fields:

        "fields": "userEnteredFormat/textFormat(bold,italic)"
However, while both elements are in the field mask, we've only provided the update data for bold. There's no data for italic setting specified in the request body. In this case, italics for all cells will be reset, meaning if the cells were originally italicized, those italics will be removed after this API request completes. And vice versa, if the cells were not italicized to begin with, they'll stay that way. This feature gives developers the ability to undo or reset any prior settings on affected range of cells. Check out the video for more examples and tips for using field masks for update requests.

To learn more about using field masks for partial response in API payloads, check out this video and the first post in this two-part series. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation. Happy field-masking!

Using field masks with update requests to Google APIs



We recently demonstrated how to use field masks to limit the amount of data that comes back via response payloads from read (GET) calls to Google APIs. Today, we’ll focus on a different use case for field masks: update requests.

In this scenario, field masks serve a different, but similar purpose—they still filter, but function more like bitmasks by controlling which API fields to update. The following video walks through several examples of update field mask usage with both the Google Sheets and Slides APIs. Check it out.
2
In the sample JSON payload below, note the request to set the cells' bold attribute to true (per the cell directive below), then notice that the field mask (fields) practically mirrors the request:
{
"repeatCell": {
"range": {
"endRowIndex": 1
},
"cell": {
"userEnteredFormat": {
"textFormat": {
"bold": true
}
}
},
"fields": "userEnteredFormat/textFormat/bold",
}
}
Now, you might think, “is that redundant?” Above, we highlighted that it takes two parts: 1) the request provides the data for the desired changes, and 2) the field mask states what should be updated, such as the userEnteredFormat/textFormat/bold attribute for all the cells in the first row. To more clearly illustrate this, let’s add something else to the mask like italics. Here, the updated field mask now has both bold and italic fields:
"fields": "userEnteredFormat/textFormat(bold,italic)"

However, while both elements are in the field mask, we’ve only provided the update data for bold. There’s no data for italic setting specified in the request body. In this case, for all cells will be reset, meaning if the cells were originally italicized, those italics will be removed after this API request completes. And vice versa, if the cells were not italicized to begin with, they’ll stay that way. This feature gives developers the ability to undo or reset any prior settings on affected range of cells. Check out the video for more examples and tips for using field masks for update requests.

To learn more about using field masks for partial response in API payloads, check out this video and the first post in this two-part series. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation.  Happy field-masking!

Using Google Sheets filters in Add-ons with Google Apps Script



Developers using Google Apps Script can now access the richer feature set of the updated Google Sheets API with the recent launch of the Advanced Sheets Service. One key benefit of using an advanced service vs. native Apps Script objects, is that developers can access current API features (without having to wait for native support to come along). For example, the advanced service allows developers to access Sheets filters which make Add-ons more engaging.

Filter functionality 

With the Sheets API, developers can already get filtered rows or set new filters on Sheets data. With the Advanced Sheet Service, developers can now have their Add-ons respect those filters and apply new filters to modify what data is visible in the Sheets UI. Plus, with any of the Apps Script advanced services, you can easily access the Sheets and other Google APIs without using the UrlFetch service nor managing the authorization flow that you’d otherwise have to perform if using the REST API directly. The snippet below will return the indexes of the filtered rows in a given Sheet. Note that it is also possible to retrieve the list of rows hidden manually, using the "hide row" menu item in Google Sheets, as indicated in the API documentation. In the code sample here, we’re only exposing rows hidden by filter.

 function getIndexesOfFilteredRows(ssId, sheetId) {
var hiddenRows = [];

// limit what's returned from the API
var fields = "sheets(data(rowMetadata(hiddenByFilter)),properties/sheetId)";
var sheets = Sheets.Spreadsheets.get(ssId, {fields: fields}).sheets;

for (var i = 0; i < sheets.length; i++) {
if (sheets[i].properties.sheetId == sheetId) {
var data = sheets[i].data;
var rows = data[0].rowMetadata;
for (var j = 0; j < rows.length; j++) {
if (rows[j].hiddenByFilter) hiddenRows.push(j);
}
}
}
return hiddenRows;
The fields parameter in the code snippet limits what's returned in the Sheets API response, requesting only the values that matter to your app. For more information, check out this page in the Sheets API doc or this recent video on field masks.

See how some Add-ons use filtering 

There are a number of Add-ons that use advanced filtering in Sheets. Here are some good examples:
  • Yet Another Mail Merge: this Add-on helps users send email campaigns from a spreadsheet and is built to process only the filtered rows of a Sheet. Let's say you have a list of people who are registered for an event, but you've only accepted some of these registrants and need to send an email confirmation. With Yet Another Mail Merge and the updated API, you can filter out people you don't approve to attend and the Add-ons skips them without sending confirmations.
  • Sankey Snip and Chord Snip: these Add-ons helps users create special chart types that aren't available in the Google Sheets UI. When respecting filters is enabled with these Add-ons, the charts will dynamically visualize filtered data. Check out the example below from the Chord Snip Add-on.
Of course the API also provides the ability to add, update or delete filters on a Sheet. This is useful if you want to quickly display rows with a specific status to your users. One example would be if you built a workflow approval Add-on. You can show the user rows that are waiting for approval. The snippet below applies the requested filter on a given Sheet—the API documentation describes a standard basic filter object:

function setSheetBasicFilter(ssId, BasicFilterSettings) {
//requests is an array of batchrequests, here we only use setBasicFilter
var requests = [
{
"setBasicFilter": {
"filter": BasicFilterSettings
}
}
];
Sheets.Spreadsheets.batchUpdate({'requests': requests}, ssId);
}

Yet Another Mail Merge, as many mass-mailing tools do, keeps track of all emails sent, opened and clicked. A tracking report is available in the spreadsheet sidebar, and clicking on the number of emails opened will automatically apply a filter to display only the matching rows—all rows with the status “opened.”

Now, you can determine filters applied in a Sheet directly through the Sheets API or through Apps Script apps and Add-ons using the Advanced Sheets Service, and continue to build the best experience for your users.

About the Authors 

Romain Vialard is a Google Developer Expert. After some years spent as a G Suite consultant, he is now focused on products for G Suite and Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.

Bruce Mcpherson is a Google Developer Expert, an independent consultant, blogger and author of Going GAS, Google Apps Script for Beginners, and Google Apps Script for Developers.

New Google Drive metrics now accessible from Reports API



You might have read that we launched new metrics in the Admin SDK Reports API to help you gain reliable, easily-validated perspectives about users within your domain. Today, we're building on these features by giving administrators and developers even greater visibility into how files are shared both inside and outside of domain. These changes include:
  1. New metrics to supplement the set of metrics we launched last year 
  2. New visibility information for audit events 
  3. Deprecation of existing metrics from the Reports API

New Metrics

We’ve created a new set of metrics to complete the set we launched last year. With these new metrics you can:
  • Gain insight into the visibility of files and their sharing state, which is useful for security and reporting. This will replace these older metrics:
    num_docs_internally_visible, num_docs_externally_visible, num_docs_shared_outside_domain.
  • Report on product adoption within your domain with summary statistics about groups of users (collaborators, viewers, creators and sharers). Take advantage of key adoption metrics such as 1-, 7-, and 30-day active users for Google Drive, Docs, Sheets, Slides, Forms, Drawings and more. 
  • Simplify your calculation of “what has changed” in your domain using delta metrics which pre-calculate changes in visibility and items owned.

New Visibility Information 

Now, new visibility information is attached to every audit event which helps you quickly identify the permission change events that lead to files being shared differently both within and outside your domain. Learn more.

Deprecating Existing Metrics 

While we’re aware of the need to have reliable and timely data about your domain’s users and files on Google Drive, Drive’s data and infrastructure has grown considerably, requiring us to make some difficult technical tradeoffs regarding metrics. As a result, today marks the beginning of a 12-month deprecation timeline that will retire these existing metrics from the Reports API and eventually the Admin Console. These metrics will no longer be available starting May 14, 2018.

To get started using the Reports API and see all the different types of metrics you can report on for your domain, check out the official documentation. We hope you find these features useful in your reporting.