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

Issue 716614 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

User continues to print after remove / disable via admin console

Project Member Reported by snambiar@chromium.org, Apr 28 2017

Issue description

Chrome Version: (copy from chrome://version) 58 Beta (not with device.. cannot recall exact version... can update later if needed)
OS: CrOS

What steps will reproduce the problem?
(1) Add a CUPS printer via User Settings in Device Management (ensure printing from device works)
(2) Remove or Disable the CUPS printer from User Settings
(3) Cached information in the device allows the user to continue using the printer

What is the expected result?
User should not be able to print to the printer that was removed / disabled.

What happens instead?
User is able to continue printing to the printer.



For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Status: Assigned (was: Untriaged)
Quick question for my understanding - Did the user's policy get refreshed? (And aside, is there a way for an Admin to force a policy refresh to users?)

Comment 2 by zhanlu@chromium.org, Apr 28 2017

There is a gap between server launch and DMserver launch. This issue should be resolved automatically next week after newest DMserver launch.

Comment 3 by zhanlu@chromium.org, Apr 28 2017

Owner: zhanlu@chromium.org

Comment 4 by zhanlu@chromium.org, Apr 28 2017

Disabling is a concept on server side and has nothing to do with client.

Comment 5 by zhanlu@chromium.org, Apr 28 2017

Also, the policy refresh mentioned in Comment 1 is another possible cause for removed printers. We need to force refresh the policy if we want to see policy change immediately. DMserver launch should only affect disabled printers.

Comment 6 by skau@chromium.org, Apr 28 2017

Cc: skau@chromium.org
zhanlu@, I'm pretty sure the problem is that the printers from policy are being cached somewhere on the client.  Is this a failure you'd expect to see with some kind of version mismatch in the management infrastructure?

Comment 7 by skau@chromium.org, Apr 28 2017

Components: Internals>Printing>CUPS Enterprise

Comment 8 by zhanlu@chromium.org, Apr 28 2017

Ah, if you cache it, it might be one cause. snambiar@, could you post the up-to-date policy? If the policy does not contain the printer but the printer still works, it is not server side issue.
@zhanlu / @weifangsun - Policy was refreshed. Checked that... reloaded a few times to ensure that. Printer still worked. As @skau pointed out, think caching is the likely reason.

Comment 10 by skau@chromium.org, May 10 2017

Status: Fixed (was: Assigned)
This should be fixed by https://codereview.chromium.org/2858353004/
Labels: VerifyIn-61

Comment 12 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment