User Settings on CrOS now shows the managed banner for enrolled devices.

User Settings on CrOS now shows the managed banner for enrolled devices.

...instead of the the "These settings may only be modified by the
owner:<blank>" as it was until now. Also correctly wired the managed state
of the local_state cache of SignedSettings prefs to be set to true when
the device is enrolled.

BUG=chromium-os:16058
TEST=Enroll the device and go to user settings. The yellow banner should be there.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=91825

[pastarmovj, 2011-06-15 14:44:28]

Can you please have a look at that CL.

[Mattias Nissler (ping if slow), 2011-06-15 15:02:59]

http://codereview.chromium.org/7171018/diff/1/chrome/browser/resources/option...
File chrome/browser/resources/options/chromeos/accounts_options.js (right):

http://codereview.chromium.org/7171018/diff/1/chrome/browser/resources/option...
chrome/browser/resources/options/chromeos/accounts_options.js:50:
OptionsPage.updateManagedBannerVisibility();
Is this call really needed? I guess you should also add someone who is more
familiar with WebUI settings to the review.

http://codereview.chromium.org/7171018/diff/1/chrome/browser/ui/options/optio...
File chrome/browser/ui/options/options_util.h (left):

http://codereview.chromium.org/7171018/diff/1/chrome/browser/ui/options/optio...
chrome/browser/ui/options/options_util.h:20: OPTIONS_PAGE_ACCOUNTS,
Why do you remove this? I thought we need it to persist which page should be
shown when the user next opens the settings dialog (at least that was the case
with the old native settings dialogs).

[pastarmovj, 2011-06-15 15:57:07]

Updated and fired some trybots.

http://codereview.chromium.org/7171018/diff/1/chrome/browser/resources/option...
File chrome/browser/resources/options/chromeos/accounts_options.js (right):

http://codereview.chromium.org/7171018/diff/1/chrome/browser/resources/option...
chrome/browser/resources/options/chromeos/accounts_options.js:50:
OptionsPage.updateManagedBannerVisibility();
On 2011/06/15 15:02:59, Mattias Nissler wrote:
> Is this call really needed? I guess you should also add someone who is more
> familiar with WebUI settings to the review.

You are right not needed here.

http://codereview.chromium.org/7171018/diff/1/chrome/browser/ui/options/optio...
File chrome/browser/ui/options/options_util.h (left):

http://codereview.chromium.org/7171018/diff/1/chrome/browser/ui/options/optio...
chrome/browser/ui/options/options_util.h:20: OPTIONS_PAGE_ACCOUNTS,
On 2011/06/15 15:02:59, Mattias Nissler wrote:
> Why do you remove this? I thought we need it to persist which page should be
> shown when the user next opens the settings dialog (at least that was the case
> with the old native settings dialogs).

This is only needed for the OptionsManagedBannerHandler. To distinguish between
which prefs should influence the banner on which page. No other references in
code exist to that enum that I could see.

[Mattias Nissler (ping if slow), 2011-06-20 08:34:42]

LGTM if you get some WebUI person to agree with me :)

[pastarmovj, 2011-06-27 15:40:18]

Hi Stuart,
I have fixed the issue that on ChromeOS devices that are enrolled thus have
their user settings controlled by device policy the banner that stated that fact
was incorrectly reusing the error for locally owned devices. 
Can you please have a look at the CL as Mattias suggested we should get someone
closer to WebUI to have a look at that CL before we land it.
Thanks!

[stuartmorgan, 2011-06-28 18:33:36]

LGTM

[commit-bot: I haz the power, 2011-07-08 09:09:36]

Change committed as 91825