[go: nahoru, domu]

Domain administrators can create new users for their domain using the control panel web UI and the Google Apps Provisioning API. Once the new users are created, editing their contact information (such as their addresses, phone numbers, etc) can be done using the Google Apps Profiles API. These profiles are shown to everybody in the organization when searching for users in GMail’s Contacts Manager and GMail’s autocomplete feature.

Some users want enhanced privacy but unsharing a user’s contact information could only be done using the control panel web UI.


We just introduced a new element in the Google Apps Profiles API that lets domain administrators set this option programmatically. This new field is called gContact:status and is available under a User Profile entry:
<gcontact:status indexed="true"/>
Changing the indexed attribute value to false unshares the user contact’s information when “contact sharing” is enabled on the domain.

For more information about the Google Apps Profiles API and code samples for supported languages using our client libraries, please refer to the developer’s guide. To learn how you can use 2-legged OAuth and batch requests to programmatically unshare users contact’s information with our client libraries, please have a look at this article.

Alain Vongsouvanh profile | events

Alain is a Developer Programs Engineer for Google Apps with a focus on Google Calendar and Google Contacts. Before Google, he graduated with his Masters in Computer Science from EPITA, France.


Want to weigh in on this topic? Discuss on Buzz


Since we launched the Google Tasks API we have received a warm welcome from the developer community on the public forum, and a lot of question on how to make it work with OAuth 2.0 on Android. Let's see how this can be done.

Android has its own native authorization flow and its own way of handling Google accounts as you can register them on your device. Since Android 2.0, the AccountManager manages the accounts that you have registered - the ones that are listed under Settings > Accounts & sync. Specifically, it handles the authorization flow and can generate authorization tokens that are required to access data using APIs.
Accounts registered in your Android environment

You can use the AccountManager to get the Google account you want to access the Tasks for. Though as the AccountManager also manages accounts from other vendors you can simply instantiate a GoogleAccountManager which is provided in the Google APIs Client library for Java and only handles Google accounts:
GoogleAccountManager googleAccountManager = new GoogleAccountManager(

activity);
Account[] accounts = accountManager.getAccounts();
If more than one Google accounts are available on the Android device you should prompt the user for the account he wishes to use through a dialog.

Now that the user has chosen an account (or if there was only 1 Google account) you can ask the AccountManager to issue an authorization token for the Tasks API. This is done by calling the AccountManager.getAuthToken() method. The AccountManager will take care of contacting the Google APIs authorization endpoint and run the AccountManagerCallback that you have defined in the method call when it has retrieved an authorization token:
googleAccountManager.manager.getAuthToken(account, AUTH_TOKEN_TYPE, null,

activity, new AccountManagerCallback<Bundle>() {
public void run(AccountManagerFuture<Bundle> future) {
try {
// If the user has authorized your application to use the tasks API
// a token is available.
String token = future.getResult().getString(
AccountManager.KEY_AUTHTOKEN);
// Now you can use the Tasks API...
useTasksAPI(token);
} catch (OperationCanceledException e) {
// TODO: The user has denied you access to the API, you
// should handle that
} catch (Exception e) {
handleException(e);
}
}
}, null);
The Android AccountManager has support for OAuth 2.0. A user friendly AUTH_TOKEN_TYPE exists for the Tasks API which will make the AccountManager return an OAuth 2.0 access token:
String AUTH_TOKEN_TYPE = ”Manage your tasks”;
During the AccountManager.getAuthToken() call the AccountManager will check if your application has been authorized to access the Tasks API. If your application has not yet been authorized the user will be presented with an authorization dialog so that they can Allow or Deny your application to use the Tasks API on their account.
Authorization dialog

Another piece of getting the Tasks API to work using OAuth 2.0 on Android is that you also need to specify an API Key when making calls to the Tasks API. The API Key is mandatory as it identifies your application and therefore allows the API to deduct quota and use the quota rules defined for your project. You can get it from the Google APIs Console at API Access > Simple API Access > API Key. You need to specify the API Key on your Tasks service Object:
useTasksAPI(String accessToken) {

// Setting up the Tasks API Service
HttpTransport transport = AndroidHttp.newCompatibleTransport();
AccessProtectedResource accessProtectedResource =
new GoogleAccessProtectedResource(accessToken);
Tasks service = new Tasks(transport, accessProtectedResource,
new JacksonFactory());
service.setKey(INSERT_YOUR_API_KEY);
service.setApplicationName("Google-TasksSample/1.0");

// TODO: now use the service to query the Tasks API
}
At this point you should have a fully setup Tasks API service Object which you can use to query the API as per the Tasks API developer’s Guide.

If you would like to get more tips and learn more about getting the Google Tasks API and OAuth 2.0 working on Android please have a look at our newly published article.

Also we recently added a new sample to the Google APIs Client Library for Java sample repository to help you getting started with the Tasks API and OAuth 2.0 on Android.

Nicolas Garnier profile | twitter | events

Nicolas joined Google’s Developer Relations in 2008. Since then he's worked on commerce oriented products such as Google Checkout and Google Base. Currently, he is working on Google Apps with a focus on the Google Calendar API, the Google Contacts API, and the Tasks API. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.


Want to weigh in on this topic? Discuss on Buzz


A recent addition to the Email Settings API allows domain administrators to use HTML-encoded strings when configuring the default signature for their users.

Updating all signatures to make them adopt the same visually appealing style sounds like a perfect task to automate, however we’d still need to collect various pieces of information for each user, such as phone number or job title, and the Email Settings API has no knowledge of them.

The Google Apps Profiles API provides exactly what we are looking for and in the rest of this article we’ll see how to have the two APIs interact to reach our goal.

Let’s assume we want our signatures to look like the one in the screenshot below, with a bold name, italic job title and clickable link for the email address. Of course you can edit the style as you like with a bit of HTML skills:


Python is the programming language of our choice for this small script and we use the Google Data APIs Python Client Library to send requests to the Email Settings and Profiles APIs.

The first few lines of the script import the required libraries and set the values of the credentials that will be used to authorize our requests. You can find the consumer key and secret for your domain in your Control Panel, under Advanced Tools - Manage OAuth domain key. Remember to replace the dummy values in the script below with yours before running it:
import gdata.apps.emailsettings.client

import gdata.contacts.client
# replace these values with yours

CONSUMER_KEY = 'mydomain.com'
CONSUMER_SECRET = 'my_consumer_secret'
company_name = 'ACME Inc.'
admin_username = 'admin'

We’ll use 2-legged OAuth as the authorization mechanism and set the administrator’s email address as the value of the xoauth_requestor_id parameter, identifying the user we are sending the requests on behalf of.

The consumer key and secret plus the requestor id are the only parameters needed to create an OAuth token that we can pass to the Email Settings and Profiles clients:
# request a 2-legged OAuth token

requestor_id = admin_username + '@' + CONSUMER_KEY
two_legged_oauth_token = gdata.gauth.TwoLeggedOAuthHmacToken(
CONSUMER_KEY, CONSUMER_SECRET, requestor_id)

# Email Settings API client
email_settings_client = gdata.apps.emailsettings.client.EmailSettingsClient(
domain=CONSUMER_KEY)
email_settings_client.auth_token = two_legged_oauth_token

# User Profiles API client
profiles_client = gdata.contacts.client.ContactsClient(
domain=CONSUMER_KEY)
profiles_client.auth_token = two_legged_oauth_token

Let’s define a class that generates the signatures for our users on the basis of a set of optional attributes (occupation, phone number, email, etc). This is the class you need to edit or extend if you want to change the style of the signatures for your domain. In the example below, the HtmlSignature() method simply concatenates some strings with hard-coded styling, but you may want to use a more elaborate templating system instead:
# helper class used to build signatures

class SignatureBuilder(object):
def HtmlSignature(self):
signature = '%s' % self.name
if self.occupation:
signature += '%s' % self.occupation
if self.company:
signature += '%s' % self.company
signature += 'Email: <a href=\'mailto:%s\'>%s</a> - Phone: %s' % (
self.email, self.email, self.phone_number)
return signature

def __init__(
self, name, company='', occupation='', email='', phone_number=''):
self.name = name
self.company = company
self.occupation = occupation
self.email = email
self.phone_number = phone_number

Let’s use profiles_client to retrieve a feed containing all profiles for the domain. Each call to GetProfilesFeed() only returns a page of users, so we need to follow the next links until we get all users:
# get all user profiles for the domain

profiles = []
feed_uri = profiles_client.GetFeedUri('profiles')
while feed_uri:
feed = profiles_client.GetProfilesFeed(uri=feed_uri)
profiles.extend(feed.entry)
feed_uri = feed.FindNextLink()

At this point profiles will contain the list of users we want to process. For each of them, we instantiate a SignatureBuilder object and set its properties name, company, occupation, email and phone_number with the data for that user.
A call to the HtmlSignature() method of the SignatureBuilder instance will provide us with a properly formatted HTML-encoded signature.
# extract relevant pieces of data for each profile

for entry in profiles:
builder = SignatureBuilder(entry.name.full_name.text)
builder.company = company_name
if entry.occupation:
builder.occupation = entry.occupation.text
for email in entry.email:
if email.primary and email.primary == 'true':
builder.email = email.address
for number in entry.phone_number:
if number.primary and number.primary == 'true':
builder.phone_number = number.text

# build the signature
signature = builder.HtmlSignature()

The Email Settings API client exposes a method called UpdateSignature to set the signature for a target user. This methods accepts two parameters, the username of the user to be affected and a string containing the signature. We just built the latter, so we only need the retrieve the unique username that identifies each user and that can be easily inferred from the entry identifier returned by the Profiles API, as described in the code and the comment below.

It is worth mentioning that you can also retrieve usernames with the Provisioning API, but for the sake of simplicity we’ll rely on this small hack:
# entry.id has the following structure:

# http://www.google.com/m8/feeds/profiles/domain/DOMAIN_NAME/full/USERNAME
# the username is the string that follows the last /
username = entry.id.text[entry.id.text.rfind('/')+1:]

It’s time to send the requests to the Email Settings API and update the signature:
# set the user's signature using the Email Settings API

email_settings_client.UpdateSignature(username=username,
signature=signature)

For further details on what can be accomplished with the Google Apps APIs, please check our documentation and don’t hesitate to reach out to us on our forums if you have any questions.



Claudio Cherubino profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.