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

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

Index: chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.cc
diff --git a/chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.cc b/chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.cc
index ec7272fa00efaa7b0c554c8437ef5c407e1b2ea4..8667e7a2496bb12a71d09862f596ffe323532fb1 100644
--- a/chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.cc
+++ b/chrome/browser/ui/webui/chromeos/login/enterprise_oauth_enrollment_screen_handler.cc
@@ -231,6 +231,10 @@ void EnterpriseOAuthEnrollmentScreenHandler::ShowEnrollmentStatus(
       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: