Add device policy definition for local accounts.

chrome/browser/policy/proto/chrome_device_policy.proto

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 
 package enterprise_management;
 
@@ skipping 202 matching lines @@
   // that are equivalent to one of the timezones in "timezone_settings.cc" are
   // valid. In case of an invalid value (e.g. the empty string), the setting is
   // still activated with a fallback timezone (currently "GMT").
   // Only if no value is provided, the timezone device setting is inactive. In
   // that case, the currently active timezone will remain in use however users
   // can change the timezone and the change is persistent. Thus a change by one
   // user affects the login-screen and all other users.
   optional string timezone = 1;
 }
 
+message DeviceLocalAccountsProto {
+  // The list of account identifiers for the device-local accounts (i.e.
+  // accounts without an associated cloud-backed profile) that are available on
+  // the device. Account identifiers follow the conventions for email addresses,
+  // e.g. user@example.com. Policy-configured device-local accounts are on the

[Bin, 2012/11/13 20:03:49]

account_id will be in the format of email address, but it may contains illegal
characters for email address (e.g enterprise-configured public account). 

Can you add this to the comment to make it clear?

[Mattias Nissler (ping if slow), 2012/11/14 13:42:48]

Done.

+  // same domain that the device is enrolled to.
+  repeated string account_id = 1;

[Bin, 2012/11/13 20:03:49]

Should we define a singular DeviceLocalAccountProto here and defined a repeated
DeviceLocalAccountProto in ChromeDeviceSettingsProto? I am okay if we wrap
another layer on top of repeated DeviceLocalAccountProto.

If we ever want to put any additional fields into one single DeviceLocalAccount,
then it is hard to add in the current scheme.

[Mattias Nissler (ping if slow), 2012/11/14 13:42:48]

I prefer not to make ChromeDeviceSettingsProto.device_local_accounts repeated,
because there are probably going to be a few global device-local account
settings (auto-login for example).

Regarding adding more fields, you have a point. I figured that a simple repeated
string field would be easier to handle when I adjusted this yesterday. Then
again, better safe than sorry. Restored the old version.

+}
+
 message ChromeDeviceSettingsProto {
   optional DevicePolicyRefreshRateProto device_policy_refresh_rate = 1;
   optional UserWhitelistProto user_whitelist = 2;
   optional GuestModeEnabledProto guest_mode_enabled = 3;
   optional DeviceProxySettingsProto device_proxy_settings = 4;
   optional CameraEnabledProto camera_enabled = 5;
   optional ShowUserNamesOnSigninProto show_user_names = 6;
   optional DataRoamingEnabledProto data_roaming_enabled = 7;
   optional AllowNewUsersProto allow_new_users = 8;
   optional MetricsEnabledProto metrics_enabled = 9;
   optional ReleaseChannelProto release_channel = 10;
   optional DeviceOpenNetworkConfigurationProto open_network_configuration = 11;
   optional DeviceReportingProto device_reporting = 12;
   optional EphemeralUsersEnabledProto ephemeral_users_enabled = 13;
   optional AppPackProto app_pack = 14;
   optional ForcedLogoutTimeoutsProto forced_logout_timeouts = 15;
   optional ScreenSaverProto login_screen_saver = 16;
   optional AutoUpdateSettingsProto auto_update_settings = 17;
   optional StartUpUrlsProto start_up_urls = 18;
   optional PinnedAppsProto pinned_apps = 19;
   optional SystemTimezoneProto system_timezone = 20;
+  optional DeviceLocalAccountsProto device_local_accounts = 21;
 }