New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 697429 link

Starred by 2 users
Status: Assigned
Owner:
igorcov@chromium.org
Cc:
atwilson@chromium.org
tnagel@chromium.org
█ bartfab@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Device policies are stored only after user log in.

Project Member Reported by igorcov@chromium.org, Mar 1 2017 
Chrome Version: 56.0.2924.87
OS: Chrome OS

What steps will reproduce the problem?
(1) Boot a device.
(2) Check the logs, to see if the device policies are stored
(3) Log in, and check the logs again

What is the expected result?
The device policies could be stored after the device boot.

What happens instead?
The device policies happen only after user log in.

The process is asynchronous and doesn't affect the user
experience, but launching it after the boot is a logical
thing to do.

Comment 1 by tnagel@chromium.org, Mar 1 2017

Labels: CodeHealth
I assume that the device you're talking about is enrolled?  Can you test whether policies are applied?  E.g. having the device sit on the login screen while changing the user whitelist in CPanel and checking whether the policy change takes effect?

Comment 2 by atwilson@chromium.org, Mar 8 2017

Cc: bartfab@chromium.org
I believe that device policy push notifications were explicitly added to address this use case. So I'm maybe OK with us not doing a proactive policy fetch on boot, as long as we *do* respond to push notifications.

What code actually is triggering the device policy refresh on user log in?
►

Sign in to add a comment