Sharing data, layers, and maps Upcoming!

This article describes upcoming changes to asset sharing and how to prepare for this transition. If your current access lists (ACLs) contain Google groups rather than individual users, you're all set. Although your current settings will be copied to the assets, future maintenance will be much easier if you use Google groups as your primary sharing mechanism. (31 March 2014)

Upcoming changes to asset sharing

We are planning to simplify sharing settings by implementing the following changes:

  • Sharing settings will be applied on a per-asset basis. Each data source, layer, and map will have its own associated sharing settings, similar to the sharing settings of a document or spreadsheet in Google Apps.
  • Access lists will no longer be used in Maps Engine. Users and groups can be added to an asset's sharing setting directly, rather than first creating the group, then adding it to an access list, and then applying the access list.
  • Each asset has two categories for sharing:
    • Draft version sharing
    • Published version sharing

This table summarizes how the two sharing categories are used:

Sharing category What it means Settings
Draft version sharing Specifies who is the owner of the asset and who can view and edit the unpublished (working draft) version of the asset. Users and groups can be listed here as "Is Owner," "Can edit," or "Can view (the same as in Google Docs, Google Spreadsheets, and other Google apps).
Published version sharing Specifies who can view the published version of the asset. Users and groups listed here "Can view" the asset after it's published (but they have no editing or publishing privileges).

Action needed!

When access list functionality is removed from Maps Engine, the users and groups in the access list currently assigned to a given asset will be transferred to that asset's sharing settings.

Here is a list of steps to take to make this transition a smooth one:

  1. Look at your current access lists. If the access lists consist of many individual usernames, follow the next steps. If the access lists consist of mostly Google groups, you're fine and don't need to do anything.
  2. Wherever possible, replace the individual usernames with Google groups that are based on functions or organizational categories. Examples of functional and organizational groups are
    • Upload team
    • Planning Department
    • Marketing
    • Field agents
    • Regional managers
    • Executive team
  3. Add the individual users to the appropriate Google group.

Although it requires an extra step to set up a Google group, it generally simplifies asset management if you create sets of users based on their roles or functions within your organization. These groups are then added to an asset's sharing settings rather than adding individuals one at a time to an asset.

Why use Google groups?

Here's why groups are preferable:

  • Reusability: Once you define a group (such as Map Editors, Data Creators, or Designers), you can reuse that group in the sharing settings of multiple assets.
  • Scalability: It's much easier to keep track of users who join or leave the company if you only include them in a few groups, rather than in the sharing settings for hundreds of individual assets.
  • Maintenance: Housekeeping is easier if users are grouped according to roles. A given user can be added to a group or deleted from it once, and sharing settings for that group are automatically updated on all assets with sharing settings that contain the group.
  • Identity: Once you've defined a Google group, anyone working with Maps Engine can simply add the group, knowing only what the name of the group represents. The asset owner doesn't need to know who the individual members are.

Example

If you have already been using Google groups in your access lists, this transition should be a smooth one. However, if you have long lists of individual users in a large number of assets, future maintenance will be cumbersome, and it will probably be painful to manage large numbers of individual users (see the section on Use Google groups to simplify sharing). For example, when per-asset sharing takes effect, each asset will have its current access list copied to its sharing settings. In the future, each asset will need to be edited individually if you add sharing at the user level.

Taking some time now to convert access lists to contain a small set of Google groups will help avoid the task of editing the sharing settings of large numbers of assets that all require individual changes. Before this conversion takes place, be sure your current access lists contain groups, not users, and that the group memberships are up to date.

For example, in the following scenario which uses Google groups, only the original Google group needs to be edited to accommodate changes in users. The assets use Google groups in their sharing setting, so the individual assets do not need to be modified when users come and go.

Creating a Google group

There are essentially two types of Google groups:

  • Public: If you are using a personal account (for example, if you are a gmail.com user), create a public Google group. Also, if you need to include users from multiple Google Apps domains, you may need to create a public Google group. (Check with your IT administrator.) To create a public Google group, go to the Google groups Home page and follow these instructions.
  • Corporate: If you are using a corporate account (for example, if you are using an account at yourcompanyname.com), follow these instructions.

Google Maps Engine API

Any code that currently references an access list (ACL) in the Google Maps Engine API (for example, Table Create) will continue to function as is. While you will not be able to modify your existing access lists after this transition, your access lists will still be functional. If the access list contains a Google group, you will be able to change who the asset is shared with by adding and removing users from the Google group. You will not be able to add or remove individual users directly from the access lists. Following the transition from the old access list model to the new per-asset sharing model, we will be releasing an API to create and edit asset ACLs.