Public Sessions: fetch device robot api token during enterprise enrollment.

chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.cc

 // 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.
 
 #include "chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.h"
 
 #include <algorithm>
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
@@ skipping 213 matching lines @@
   NOTREACHED();
 }
 
 void EnterpriseOAuthEnrollmentScreenHandler::ShowEnrollmentStatus(
     policy::EnrollmentStatus status) {
   switch (status.status()) {
     case policy::EnrollmentStatus::STATUS_SUCCESS:
       ShowStep(kEnrollmentStepSuccess);
       return;
     case policy::EnrollmentStatus::STATUS_REGISTRATION_FAILED:
+    // TODO: have specific messaging for robot auth errors?  Seems to low-level
+    // for users to do anything about?

[Mattias Nissler (ping if slow), 2013/03/19 06:33:08]

We thought so too in the first iteration of this code :) It is actually rather
helpful to have separate error messages, so we can handle bug reports, so please
do add two additional messages here.

[David Roche, 2013/04/02 01:59:25]

Okay.  I didn't want to clutter it up with extra messages, but I'd certainly
like to know if this is the step that's failing, so sounds good to me.

Let me know if you have any feedback on the wording of the messages.

[Mattias Nissler (ping if slow), 2013/04/02 14:16:46]

We'll have to tell chrome-ui-review@ about the strings. I have a long thread
about enrollment error messages with Glen already that didn't come to a
conclusion :)

[David Roche, 2013/04/04 01:39:53]

How should I go about this?  Should I start a new thread, or continue the one
you have with Glen?

Should we somehow separate the strings issue from this CL, perhaps by reverting
to the generic error message, and pushing the strings into another CL?  I'd
rather see the code checked in soon, so end-to-end testing can be easily
started, than have the code get old while we iterate on the details of two error
strings.

[Mattias Nissler (ping if slow), 2013/04/04 13:18:34]

In this case (only error messsages) I think it's OK to just commit and then send
a mail saying "btw. there are new strings here". We can then fix up the strings
when changes are requested.

+    case policy::EnrollmentStatus::STATUS_ROBOT_AUTH_FETCH_FAILED:
+    case policy::EnrollmentStatus::STATUS_ROBOT_REFRESH_FETCH_FAILED:
       // Some special cases for generating a nicer message that's more helpful.
       switch (status.client_status()) {
         case policy::DM_STATUS_SERVICE_MISSING_LICENSES:
           ShowError(IDS_ENTERPRISE_ENROLLMENT_MISSING_LICENSES_ERROR, true);
           break;
         case policy::DM_STATUS_SERVICE_MANAGEMENT_NOT_SUPPORTED:
           ShowError(IDS_ENTERPRISE_ENROLLMENT_ACCOUNT_ERROR, true);
           break;
         default:
           ShowErrorMessage(
@@ skipping 277 matching lines @@
   screen_data.SetBoolean("is_auto_enrollment", is_auto_enrollment_);
   if (!test_email_.empty()) {
     screen_data.SetString("test_email", test_email_);
     screen_data.SetString("test_password", test_password_);
   }
 
   ShowScreen(OobeUI::kScreenOobeEnrollment, &screen_data);
 }
 
 }  // namespace chromeos