WorryFree Computers   »   [go: up one dir, main page]



If you’re a G Suite admin (or a developer creating apps for admins), it’s important to understand the various applications your company’s employees are using and how they’re accessing them. Today, we’re making that easier by introducing app identification (i.e. originating_app_id) in the Google Drive audit logs within the Admin SDK Reports API.

Now, your apps will be able to determine whether an activity logged was performed by a user in the Drive Android app, Drive iOS app, Google Chrome, or through a variety of other third-party apps that leverage, modify or create files within Google Drive, like Smartsheet or Asana. This will give you a better sense of the apps being used in your organization, as well as the extent and context of that usage.

Note that App IDs that show up in the logs will be numeric. Should you want to retrieve app names, a separate request using the Google Drive REST API is needed. If you already retrieve information through the Drive activity request, you should start seeing the originating_app_ids show up in your logs. Here are a pair of HTTP requests you can use to query this information:

GET 
https://www.googleapis.com/admin/reports/v1/activity/users/userKey

Or
GET 
https://www.googleapis.com/admin/reports/v1/activity/users/all/applications/drive

To learn more about this new feature, take a look at the documentation, then integrate into your code so you and other G Suite admins can gain a better understanding of app usage in your domain(s). We look forward to seeing what you build!



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.


You may have read recently that the Google Cloud Platform team upgraded to Issue Tracker, the same system that Google uses internally. This allows for improved collaboration between all of us and all of you. Issues you file will have better exposure internally, and you get improved transparency in terms of seeing the issues we’re actively working on. Starting today, G Suite developers will also have a new issue tracker to which we’ve already migrated existing issues from previous systems. Whether it’s a bug that you’ve found, or if you wish to submit a favorite feature request, the new issue tracker is here for you. Heads up, you need to be logged in with your Google credentials to view or update issues in the tracker.
The new issue tracker for G Suite developers. 

Each G Suite API and developer tool has its own “component” number that you can search. For your convenience, below is the entire list. You may browse for issues relevant to the Google APIs that you’re using, or click on the convenience links to report an issue or request a new/missing feature:
To get started, take a look at the documentation pages, as well as the FAQ. For more details, be sure to check out the Google Cloud Platform announcement, too. We look forward to working more closely with all of you soon!

Posted by Shashank Gupta, Product Manager, Google Apps for Work and Wesley Chun, Developer Advocate, Google Apps
Back in 2013, we launched the Google Apps Admin SDK, and later announced as a result that several outdated Apps Admin APIs would be deprecated and shut down in April 2015. Today, we are continuing this effort of removing older, less-used functionality by announcing the deprecation of the GData Admin Settings API. Some GData API functionality will find a replacement from an Admin SDK counterpart, while other features will be discontinued. The following table summarizes which features will be retained (and where to access replacement functionality) and which won’t:
Admin Settings API
Endpoint
Post-Deprecation Replacement (if any)
no replacement / discontinued
no replacement / discontinued
no replacement / discontinued
no replacement / discontinued
no replacement / discontinued
All endpoints
no replacement / discontinued
All endpoints
no replacement / discontinued
All endpoints
replacement API coming before Aug 2017
All endpoints
no replacement / discontinued
To summarize, the GData Admin Settings API is being deprecated today and will remain operational for until October 31, 2018, to give developers time to migrate. This means that on October 31, 2018, this deprecated API will be shut down.

Posted by Sumit Chatterjee, Product Manager, Google Mobile Management and Wesley Chun, Developer Advocate, Google Apps

As security on mobile devices becomes increasingly important, we want to give Google Apps administrators the visibility to monitor key activities occurring on managed devices in their domain. With that in mind, today we are launching Mobile Audit for Google Apps Unlimited users, which audits activities on iOS and Android devices (using the native iOS Sync and Android Sync protocols) managed by Google Mobile Management. Examples of activities that are recorded include: operating system updates, device settings changes, and mobile application installs, updates and removals.

Google Apps Administrators can also go to the Reports page in the Admin console to see all the Mobile Audit events. Below is an example of what this page looks like querying one user’s activity, including newly registered devices:

Mobile Audit report and alert creation for a single user in the Admin console

As part of this launch, we are excited to make all Mobile Audit events available programmatically through the Admin SDK Reports API via Mobile Audit Activity Events. The Admin SDK is accessible through its REST API or Google Apps Script. With this new feature, administrators will be able to query all of the Mobile Audit information by user, by device, or by event, as well as verify that all of your deployed devices are running the latest security updates. You can even send this information to an asset management system to track all of your mobile inventory.

For example, if we wanted to download all of the newly registered devices, you could make a call like this to the API (via Google Apps Script):


AdminReports.Activities.list('all', 'mobile', {
      eventName: "DEVICE_REGISTER_UNREGISTER_EVENT",
      filters: "ACCOUNT_STATE==REGISTERED",
      maxResults: 1000
    });

Once you have the response from the API, you could easily parse through that data, including device models, serial numbers, user email addresses, and any other relevant information to help you track your inventory.

A more critical use case that mobile administrators have been asking for is a way to take proactive actions on devices without requiring manual intervention. For example, a mobile administrator may want to automatically block a device when something suspicious is detected. This new feature enables admins to write simple apps that do just that.

Using the Mobile Audit Activity Events in the Reports API and the Mobile Devices component of the Directory API, administrators can create scheduled scripts to check for devices that are reporting suspicious activity, and then take actions on those devices.

The Apps Script snippet below returns results if there are any mobile audit events for suspicious activity:

var response = AdminReports.Activities.list('all', 'mobile', {
      eventName: "SUSPICIOUS_ACTIVITY_EVENT",
      maxResults: 1000
    });

If there are results, the code below shows you how to retrieve the unique Google identifier for those devices, via the “RESOURCE_ID” parameter. Note that this snippet only assumes a single device reporting suspicious activity—you’ll need to tweak the code to support more than one.

var parameters = response.items[0].events[0].parameters;
var resourceId;
for (i = 0; i < parameters.length; i++) {
  if (parameters[i].name == ‘RESOURCE_ID’) {
    resourceId = parameters[i].value;
    break;
  }
}

Now the Directory API can be invoked to block the device that corresponds with the above unique identifier using this Apps Script snippet:

AdminDirectory.Mobiledevices.action('my_customer', resourceId, {
      action: "block"
    });

We are really excited to see what uses you have for Mobile Audit in the Reports API. For more information and to get started, please see the Developer Guide, reference documentation, and the Help Center. (NOTE: Again, this feature is available only to our customers with users on the Google Apps Unlimited license.)

Posted by Muzammil Esmail, Product Manager, Google for Work and Wesley Chun, Developer Advocate, Google Apps

Over the 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 services offer developers improvements over previous functionality and introduces new features that help Apps administrators better manage their domains.

To deliver even more granular control, today we are announcing the new Calendar Resource API as part of the Admin SDK’s Directory API that enables Google for Work customers to manage their physical resources, like conference rooms, printers, nap pods, tennis courts, walkstations, etc. These physical resources can be added to meetings by end users as needed. The API released today replaces the GDATA Calendar Resource API, so we encourage developers to begin moving their applications and tools to the new API. Please note that we will begin deprecation in January 2016 and sunset the existing API in January 2017. Stay tuned for a formal deprecation announcement with details.

Posted by Rishi Dhand, Product Manager, Google Apps Admin SDK and Wesley Chun, Developer Advocate, Google Apps

In a Google Apps domain, Admin role management (i.e. create, assign, and update admin roles) is a critical function for super admins that helps them distribute admin responsibilities in a more secure manner. Until now, this functionality was only available via the Admin console UI.


This is what Role management looks like in the Admin console, but now you can also do this programmatically with the Roles API.


Today’s launch of the Roles API (one of the Admin SDK Directory APIs) enables developers to build admin tools that can perform role management programmatically.

This new API will be useful to admins who have either built internal admin tools using the Admin SDK, or developers of third-party admin tools. Both can now use the Roles API to provide selective access to Delegated Admins (DAs) to specific admin capabilities within third-party applications.

Here are some examples of use cases where the Roles API can be leveraged:

  • A third-party user management app that relies on the Admin SDK to perform various user related operations can now use the Roles API to selectively show the capabilities of User management DAs, such as creating/deleting users or resetting passwords.
  • A mobile device management (MDM) app developer looking to build a tool for access by Mobile Management DAs can use the Roles API to determine the privileges of the logged-in DA and selectively display MDM related admin functionality.
  • Admins (or admin tools) can now programmatically create reports on admin role assignments which can help super admins better manage access to DAs.

For more information and to get started, please check out the Roles API documentation. We look forward to helping more admins manage their domains in a more programmatic way so they can focus on more critical aspects of managing their corporate IT infrastructure.

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.

In the last few months, we've added a number of new features to Google Apps Script, including add-ons for Sheets and Docs and 7 new advanced services.

We're eager to maintain that momentum — focusing on new features that help you do more with Google Apps. As a result, we're deprecating two Apps Script services for which good replacements exist elsewhere: ScriptDB (a NoSQL database that has been marked as experimental since it was introduced) and the Domain service (which encapsulates the GroupsManager, NicknameManager, and UserManager global objects).

Both ScriptDB and the Domain service will be turned off on November 20, 2014.

Before then, you'll need to port any ScriptDB projects to another data store, like Google Cloud SQL or a third-party NoSQL database. We've created a migration guide that explains how to export your data from ScriptDB and suggests a few alternate data stores. We have also improved the documentation for connecting to external databases through JDBC to make it a little easier for you to set up Cloud SQL with Apps Script.

The Domain service, which only Google Apps domain administrators can use, is replaced by the recently added Admin SDK Directory and Admin SDK Reports advanced services. Those advanced services also provide many new features that the Domain service does not — like managing users' devices, OAuth tokens, and application-specific passwords — so we expect that you'll prefer using them in the future.


Saurabh Gupta   profile | twitter | blog

As the product manager for Google Apps Script, Saurabh is responsible for Apps Script’s overall vision and direction.

Since we launched the Admin SDK in May 2013, we’ve been constantly improving it based on your feedback and feature requests. Our first API updates of 2014 bring some features at the top of your requests: push notifications for users, push notifications for activities, and structured user search.


Push notifications for users

Tired of polling user resources to detect changes? With push notifications for users, you can watch for changes to user resources and receive notifications from the Directory API whenever a watched user resource changes.

Check out our user notifications developer guide to learn how to improve the performances of your application by eliminating the extra network and compute costs involved with polling user resources.


Push notifications for activities

Do you want to be notified when changes to a certain document occur or specific events such as the change of a user’s password happen? With push notifications for activities you can watch for changes to activities resources, and receive notifications from the Reports API whenever a watched activity resource changes.

Check out our activities notifications developer guide to learn how to receive notifications for the activities of your interest.


Structured user search

Do you want to know which users in your domain are members of a certain organization, or which users have a common manager in their reporting chain? The new query parameter we’ve just added to the users.list method of the Directory API allows you to perform rich queries over most attributes from the user profile.

For example, you can now retrieve all the users in the Human Resources org by using the query:

orgName='Human Resources'
Or you can retrieve all the users with janesmith@example.com in their reporting chain by using the query:
manager='janesmith@example.com'

Check out our user search developer guide for a more comprehensive guide on how to build your queries and more examples of what you can do.

Silvano Luciani  

Silvano is a Developer Programs Engineer on Google's Admin SDK. Before joining Google in 2011, he has worked in Finland, Italy, Spain and the UK, writing web based configuration management tools for ISPs, social networks, web based training materials, e-commerce apps and more.