If you’re a Google Apps administrator and you want to create multiple Google Groups for your domain, you can do so using the Google Apps Provisioning API. However, until today, there was no way for you to programmatically update the settings for the groups you created. Some organizations have hundreds or even thousands of groups, and you’ve told us that you want a more streamlined method for managing these groups’ settings. That’s why we’re pleased to announce the Google Apps Groups Settings API, which allows you to control settings for all of your groups much more efficiently.
The Google Apps Groups Settings API is available for Google Apps for Business, Education and ISPs and can be used to manage:
To begin using the Google Groups Settings API today, follow the instructions in the API documentation. You will need to sign in to the Google APIs Console and request access to the API. We hope the API will allow you to more quickly and easily manage all of the groups in your domain. If you have any questions about this API, please ask them in the Domain Information and Management APIs forum.
Editor's note: This has been cross-posted from the Google Code blog -- Ryan Boyd
In March, we announced that all of the Google Web APIs adopted support for OAuth 2.0. It is the recommended authorization mechanism when using Google Web APIs.
Today, we are announcing the OAuth 2.0 Playground, which simplifies experimentation with the OAuth 2.0 protocol and APIs that use the protocol. Trying out some requests in the OAuth 2.0 playground can help you understand how the protocol functions and make life easier when the time comes to use OAuth in your own code.
Selecting the APIs to authorize
With the OAuth 2.0 Playground, you can walk through each step of the OAuth 2.0 flow for server-side web applications: authorizing API scopes (screen shot above), exchanging authorization tokens (screen shot below), refreshing access tokens, and sending authorized requests to API endpoints. At each step, the Playground displays the full HTTP requests and responses.
The OAuth Playground can also use custom OAuth endpoints in order to test non-Google APIs that support OAuth 2.0 draft 10.
OAuth configuration screen
You can click the link button to generate a link to a specific Playground state. This allows quick access to replay specific requests at a later time.
Generating a deep link to the playground’s current state
Please feel free to try the OAuth 2.0 Playground. We are happy to receive any feedback, bugs, or questions in the OAuth Playground forum.
Two weeks ago, we had our inaugural Office Hours on Google+ Hangouts, bringing together Google Apps developers from the UK, Ireland, Russia, Brazil, Germany and the US to chat. Everyone asked great questions and provided feedback on many of the APIs. It was also exciting that Google+ for Google Apps was announced at the same time as our hangout.
Given the strong interest in these Office Hours, we’re going to continue doing Hangouts with the Google Apps developer community. Some will be general Hangouts where all types of questions related to the Google Apps APIs will be welcome. Others will be focused on individual products and include core software engineers and product managers who are building the APIs you love.
Here’s the next couple: Tomorrow, November 8th @ 11:30am PST (General Office Hours) November 16th @ 10am PST (Google Apps Script team)
We’ll continue adding more Office Hours on the events calendar, and announce them on @GoogleAppsDev and our personal Google+ profiles.
Hope you’ll hang out with us soon!
The OAuth Playground is a great tool to learn how the OAuth flow works. But at the same time it can be used to generate a "long-lived" access token that can be stored, and used later by applications to access data through calls to APIs. These tokens can be used to make command line tools or to run batch jobs.
In this example, I will be using this token and making calls to the Google Provisioning API using the Python client library for Google Data APIs. But the following method can be used for any of the Google Data APIs. This method requires the token is pushed on the token_store, which is list of all the tokens that get generated in the process of using Python client libraries. In general, the library takes care of it. But in cases where it’s easier to request a token out of band, it can be a useful technique.
token_store
Step 1: Generate an Access token using the OAuth Playground. Go through the following process on the OAuth Playground interface:
consumer_key
consumer_secret
After entering all the required details you need to press these buttons on the OAuth Playground in sequence:
After the last step the text field captioned auth_token in the OAuth Playground has the required Access token and that captioned access_token_secret has the corresponding token secret to be used later.
Step 2: Use the above token when making calls to the API using a Python Client Library.
Here is an example in Python which uses the OAuth access token that was generated from OAuth Playground to retrieve data for a user.
CONSUMER_KEY = “CONSUMER_KEY” CONSUMER_SECRET = “CONSUMER_SECRET” SIG_METHOD = gdata.auth.OAuthSignatureMethod.HMAC_SHA1 TOKEN = “GENERATED_TOKEN_FROM_PLAYGROUND” TOKEN_SECRET = “GENERATED_TOKEN_SECRET_FROM_PLAYGROUND” DOMAIN = “your_domain” client = gdata.apps.service.AppsService(source=”app”, domain=DOMAIN) client.SetOAuthInputParameters(SIG_METHOD, CONSUMER_KEY, consumer_secret=CONSUMER_SECRET) temp_token = gdata.auth.OAuthToken(key=TOKEN, secret=TOKEN_SECRET); temp_token.oauth_input_params = client.GetOAuthInputParameters() client.SetOAuthToken(temp_token) #Make the API calls user_info = client.RetrieveUser(“username”)
It is important to explicitly set the input parameters as shown above. Whenever you call SetOuthToken it creates a new token and pushes it into the token_store. That becomes the current token. Even if you call SetOauthToken and SetOAuthInputParameters back to back, it won’t set the input params for the token you set.
SetOuthToken
SetOauthToken
SetOAuthInputParameters
You can use the long-lived token to make command line requests, for example using cURL. It can be useful when you need to counter-check bugs in the client library and to test new features or try to reproduce issues. In most cases, developers should use the client libraries as they are designed, as in this example.
Sometimes you want to cache data in your script. For example, there’s a RSS feed you want to use and a UiApp that you’ve built to view and process the feed. Up until now, each operation to work on the feed would require re-fetching the feed, which can get slow.
UiApp
Enter the newly launched CacheService which will allow for caching resources between script executions. Like the recently announced LockService, there are two kinds of caches: a public cache that is per-script, and a private cache which is per-user, per-script. The private cache should be used to store user-specific data, while the public cache is used to store strings that should be accessible no matter who calls the script.
So for our example feed viewer/processor, you’d already have a function to retrieve and process the feed. In order to use the CacheService, you’d wrap it like this:
function getFeed() { var cache = CacheService.getPublicCache(); var value = cache.get(“my rss feed”); if (value == null) { // code to fetch the contents of the feed and store it in value // here (assumes value is a string) // cache will be good for around 3600 seconds (1 hour) cache.put(“my rss feed”, value, 3600); } return value; }
The cache doesn’t guarantee that you won’t have to fetch it again sooner, but will make a best effort to retain it for that long, and expire it quickly after the time passes. Now you can call getFeed() often and it won’t re-fetch the feed from the remote site on each script execution, resulting in improved performance.
getFeed()
Check out the CacheService documentation for more information.
Here’s the scenario: you create a form, you have a script that triggers onFormSubmit and all is well... until it gets popular. Occasionally you start having interlacing modifications from separate invocations of your script to the spreadsheet. Clearly, this kind of interlacing is not what you intended for the script to do. Up until now, there was no good solution to this problem -- except to remain unpopular or just be lucky. Neither are great solutions.
onFormSubmit
Now, my friend, you are in luck! We’ve just launched the LockService to deal with exactly this problem. The LockService allows you to have only one invocation of the script or portions thereof run at a time. Others that would’ve run at the same time can now be made to wait nicely in line for their turn. Just like the line at the checkout counter.
The LockService can provide two different kinds of locks-- one that locks for any invocation of your script, called a public lock, and another that locks only invocations by the same user on your script, called a private lock. If you’re not sure, using a public lock is the safest bet.
For example, in the scenario in the previous paragraph you would want something like this:
function onFormSubmit() { // we want a public lock, one that locks for all invocations var lock = LockService.getPublicLock(); lock.waitLock(30000); // wait 30 seconds before conceding defeat. // got the lock, you may now proceed ...whatever it used to do here.... lock.releaseLock(); }
It’s best to release the lock at the end, but if you don’t, any locks you hold will be released at the end of script execution. How long should you wait? It depends on two things mainly: how long the thing you’re going to do while holding the lock takes, and how many concurrent executions you expect. Multiply those two and you’ll get your timeout. A number like 30 seconds should handle a good number of cases. Another way to pick the number is frankly to take an educated guess and if you guess too short, the script will occasionally fail.
If you want to avoid total failure if you can’t get the lock, you also have the option trying to get the lock and doing something else in the event of not being able to get it:
function someFunction() { var lock = LockService.getPublicLock(); if (lock.tryLock(30000)) { // I got the lock! Wo000t!!!11 Do whatever I was going to do! } else { // I couldn’t get the lock, now for plan B :( GmailApp.sendEmail(“admin@example.com”, “epic fail”, “lock acquisition fail!”); } }
So now your scripts can be as popular as they can get with no worries about messing up shared resources due to concurrent edits! Check out the LockService documentation for more information.
We are currently rolling out a change to the organization of existing resources in collections in Google Docs. This change is completely transparent to users of the Google Docs web user interface, but it is technically visible when using the Google Documents List API to make requests with the showroot=true query parameter or specifically querying the contents of the root collection. In order to understand this change, first read how Google Docs organizes resources.
showroot=true
The change involves Google removing those resources from a user’s root collection that already exist within another collection accessible to the given user. That is, if “My Presentation” is currently in root and in the “My Talks” collection, after this change it will only exist in the “My Talks” collection.
We are making this change in order to make the organization of resources less confusing for API developers. This change allows clients to know that a resource either exists in root or in some collection under root. Clients can still retrieve all resources, regardless of which collections they’re in, using the resources feed.
The change is rolling out gradually to all Google Docs users over the next few months.
Developers with further questions about this change should post in the Google Documents List API forum.
