Print Preview Default printer policy is filtering shared-to-device printers as cloud, not local |
|||||||||||
Issue description
Version: 49
OS: CrOS 7834.70.0
What steps will reproduce the problem?
(1) Share a GCP printer named "myprinter" to an OU of devices in the admin console. Printer should not be shared directly with users or groups, only via admin console.
(2) Set the DefaultPrinterPolicy for an OU in admin console. From chrome://policy on client, policy should look like:
{"namePattern":"^myprinter$","kind":"local"}
so that it matches myprinter exactly (and only myprinter) for local printers.
(3) Log in as a user in the OU from (2) and on device in OU from (1). Confirm user has "myprinter" as an option under "Local Destinations" (not concerned with default printer selection yet). GCP Printers shared via admin console OUs to devices show under "Local Destinations"
(4) Log off and delete the user profile, then log back in as the user (recreating profile ensures default printer regex is used).
What is the expected output?
The "local" printer shared with the device via the admin console should be the default selection the 1st time the user hits CTRL+P.
What do you see instead?
The "local" printer shared with the device via the admin console IS NOT selected as the default, default goes to "Print to PDF".
Non-intuitively, switching the policy to using "Cloud" or "Cloud and Local" allows the local printer which is shared via admin console to be the default selection.
Please use labels and text to provide additional information.
It appears that for the print preview UI, we place printers shared with the device via admin console under "Local destinations". However, for the purpose of the Default Printer selection policy, we consider these cloud printers. The distinction is confusing to admins.
Ideally, we should be matching printers shared to the device via admin console against the regex if "local" is the selected type. If that change is not possible then we should clarify that for the purpose of this policy, printers shared to devices via the admin console are considered "cloud" printers.
,
May 31 2016
Vidya, are we able to take a look at this?
,
Jun 2 2016
,
Jun 2 2016
Per triage: hey Matt, since you are working closely with printers, can you please recommend a course of action and reassign as you see fit? Thanks.
,
Jun 2 2016
,
Jun 3 2016
I don't know why GCP printers shared via the admin console would show up as local printers rather than GCP printers? This seems like a confusing distinction to me. I don't have context, but it would seem to me that placing this printer under the GCP section (unless it is set up for local printing using GCP 2.0) would be a better fix. If it's set up for local printing using GCP 2.0, then I'd say put it in the local section and treat it as a 'local' device for string matching. +bblietz in case he has further context here. Regardless of placement however, the DefaultPrinterPolicy string should be consistent with where a printer shows up in the print dialog, so this should be fixed. Assigning to Saswat to see if there are resources on the ent side to make this fix.
,
Jun 7 2016
Assigning this over to dskaram since he might have resources to put a fix into play. Perhaps we could combine this work w/ the work needed for Issue 536169?
,
Jun 8 2016
The enterprise team never worked with printing, it was the cloud print team that put all those policies in place so we don't really have anyone who knows any of this code. Let's discuss in the call today how best to approach this.
,
Jun 8 2016
This is on the agenda for our enterprise sync next week. Brian (GCP PM) is OOO this week, but perhaps he can pop in for the second half of our sync next week to help handle this if they are the right owner for the change.
,
Jun 8 2016
,
Jun 24 2016
Lei - can you have a look at this bug and comment on who should own this on the Chrome side?
,
Jul 31 2016
,
Oct 6 2016
alekseys@ wrote it last year with r354604. Can you convince him to take a look? If not, I can add it to my long list of bugs and figure it out eventually.
,
Nov 10 2016
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by jayhlee@google.com
, May 31 2016