Added affiliation IDs for the new affiliation determination.

components/policy/proto/device_management_backend.proto

Index: components/policy/proto/device_management_backend.proto
diff --git a/components/policy/proto/device_management_backend.proto b/components/policy/proto/device_management_backend.proto
index d196a4c015718ed46fd8adb57e5709bd2ecc31b8..42705064540097259b55b06796e519f9be8c4d46 100644
--- a/components/policy/proto/device_management_backend.proto
+++ b/components/policy/proto/device_management_backend.proto
@@ -377,6 +377,18 @@ message PolicyData {
   // The unique directory api ID of the device which was generated on the
   // server-side.
   optional string directory_api_id = 22;
+  
+  // List of device affiliation IDs. If exists overlap between user
+  // affiliation IDs and device affiliation IDs, we consider that the user is
+  // affiliated on the device. Otherwise the user is not affiliated on the
+  // device. Should be fetched with device policy. Ignored if fetched with 
+  // other polices.
+  repeated string device_affiliation_ids = 23;
+  
+  // List of user affiliation IDs. The list is used to define if current user
+  // is affiliated on the device. See device_affiliation_ids for details. 
+  // Should be fetched with user policy. Ignored if fetched with other polices.
+  repeated string user_affiliation_ids = 24;

[Mattias Nissler (ping if slow), 2015/07/30 12:10:57]

Is there a good reason to have two different fields for this? It seems that
using the same field would work fine, given that user policy and device policy
will always have a separate PolicyFetchResponse, and hence separate PolicyData
messages.

[peletskyi, 2015/07/30 14:10:58]

Both approaches have minuses. If we use only one list, this will lead  to usage
the same variable for different purposes in different case.
I and Drew stopped on this approach because
1. Maybe we will fetch both device and user IDs in the same policy in future.
2. If because of an error device affiliation IDs are sent with user policy, they
will be just ignored. No error occurred.
3. Easy to use. In code it is clear how to use user/device affiliation IDs. In
case of one field it may be complicated to understand for new developers how
this feature works because we will always refer to affiliation_id, that will
have different meaning in each case.

[Mattias Nissler (ping if slow), 2015/07/30 15:34:08]

Fair enough.

 }
 
 message PolicyFetchResponse {