Define Print Preview default printer selection policy

Define Print Preview default printer selection policy.

1) Define new policy PrintPreviewDefaultPrinterSelection and
corresponding command line switch default-printer-selection-rules
2) When this policy is defined, it takes precedence over default system
printer
3) In case of failures, fall back to the default system printer first
and only when to "Save to PDF"

The policy value is a serialized JSON string, conforming to the following
schema:
{
  "type": "object",
  "properties": {
    "kind": {
      "type": {
        "enum": [ "local", "cloud" ]
      }
    },
    "idPattern": {
      "type": "string"
    },
    "namePattern": {
      "type": "string"
    }
  }
}

BUG=468447
Committed: https://crrev.com/4b26916d54c1068cd7e67ecdcdd03f36ebc23dcf
Cr-Commit-Position: refs/heads/master@{#354604}

[Aleksey Shlyapnikov, 2015-09-24 21:19:45]

alekseys@chromium.org changed reviewers:
+ alekseys@chromium.org, cawarren@chromium.org, vitalybuka@chromium.org

[Vitaly Buka (NO REVIEWS), 2015-09-28 04:10:50]

The CQ bit was checked by vitalybuka@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-28 04:10:58]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/1

[Vitaly Buka (NO REVIEWS), 2015-09-28 04:12:13]

lgtm

https://codereview.chromium.org/1368013004/diff/1/chrome/browser/resources/pr...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/1368013004/diff/1/chrome/browser/resources/pr...
chrome/browser/resources/print_preview/data/destination_store.js:475: origin,
you don't have to do this one per line

https://codereview.chromium.org/1368013004/diff/1/chrome/browser/resources/pr...
chrome/browser/resources/print_preview/data/destination_store.js:623: if
(!isLocal && !isCloud) {
Why do you need to restrict to only these types.

[commit-bot: I haz the power, 2015-09-28 05:16:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-28 05:16:26]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Vitaly Buka (NO REVIEWS), 2015-09-28 17:20:01]

The CQ bit was checked by vitalybuka@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-28 17:22:06]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/1

[commit-bot: I haz the power, 2015-09-28 17:56:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-28 17:56:44]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Aleksey Shlyapnikov, 2015-09-29 18:15:37]

The CQ bit was checked by alekseys@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-29 18:16:03]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/20001

[commit-bot: I haz the power, 2015-09-29 18:22:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-29 18:22:19]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Aleksey Shlyapnikov, 2015-09-29 20:58:08]

The CQ bit was checked by alekseys@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-29 20:59:37]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/20001

[cawarren, 2015-09-29 21:22:31]

On 2015/09/29 20:59:37, commit-bot: I haz the power wrote:
> Dry run: CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1368013004/20001
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1368013004/20001

lgtm

[commit-bot: I haz the power, 2015-09-29 22:07:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-29 22:07:44]

Dry run: This issue passed the CQ dry run.

[Aleksey Shlyapnikov, 2015-09-30 18:38:09]

alekseys@chromium.org changed reviewers:
+ asvitkine@chromium.org

[Aleksey Shlyapnikov, 2015-09-30 18:42:26]

alekseys@chromium.org changed reviewers:
+ atwilson@chromium.org

[Aleksey Shlyapnikov, 2015-09-30 18:44:37]

alekseys@chromium.org changed reviewers:
+ gab@chromium.org

[Aleksey Shlyapnikov, 2015-10-05 17:23:55]

alekseys@chromium.org changed reviewers:
+ erg@chromium.org

[Aleksey Shlyapnikov, 2015-10-05 17:23:55]

asvitkine:
  tools/metrics/histograms/histograms.xml
atwilson
  chrome/browser/policy/configuration_policy_handler_list_factory.cc
  chrome/common/chrome_switches.*
  chrome/common/pref_names.*
  chrome/test/data/policy/policy_test_cases.json
  components/policy/resources/policy_templates.json
cawarren
  components/policy/resources/policy_templates.json, description text and
overall concept
erg
  chrome/browser/profiles/profile_impl.cc
gab
  chrome/browser/prefs/command_line_pref_store.cc
vitalybuka
  chrome/browser/resources/print_preview/data/app_state.js
  chrome/browser/resources/print_preview/data/destination_store.js
  chrome/browser/resources/print_preview/native_layer.js
  chrome/browser/resources/print_preview/print_preview.js
  chrome/browser/ui/webui/print_preview/print_preview_handler.cc
  chrome/test/data/webui/print_preview.js

[Alexei Svitkine (slow), 2015-10-05 17:24:33]

histograms lgtm

[Elliot Glaysher, 2015-10-05 17:28:29]

profiles lgtm

[gab, 2015-10-07 20:34:31]

chrome/browser/prefs/command_line_pref_store.cc lgtm stamp

[Andrew T Wilson (Slow), 2015-10-09 12:49:25]

atwilson@chromium.org changed reviewers:
+ tnagel@chromium.org

[Andrew T Wilson (Slow), 2015-10-09 12:49:45]

I won't have time to review this - Thiemo, can you take a look at this new
policy implementation?

[Thiemo Nagel, 2015-10-09 16:35:48]

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
File chrome/common/chrome_switches.cc (right):

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
chrome/common/chrome_switches.cc:319: "default-printer-selection-rules";
Adding command line switches is not allowed unless there's a good reason for it.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4113: 'name':
'PrintPreviewDefaultPrinterSelection',
Why not just DefaultPrinterSelection?

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4116: 'supported_on':
['chrome.*:47-', 'chrome_os:47-'],
47 has sailed.  Please change to 48.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4121: 'example_value': '{
"kind": "cloud", "namePattern": ".*Color" }',
Please include an idPattern in the example, too.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4124: 'desc': '''Overrides <ph
name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> Print Preview default printer
selection rules.
How about:

This policy determines the rules for selecting the default printer in <ph
name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> which happens the first time
the print function is used with a profile.

(I'd suggest to avoid the term "Print Preview" because users may not know what
it means.  Probably to them it is just "printing".  Also the headline of the
print preview page is just "Print".)

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4128: When this policy is set,
Print Preview will attempt to find a printer matching the specified attributes,
printer type, printer id or name patterns, and select it as the current one.
Please be more precise about how the final condition is assembled.  (I'm
guessing "kind && (idPattern || namePattern)" but this is not very clear from
the description.)

To be clearer:
"select it as the current one" --> "select it as default printer"

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4136: "kind": {
"kind" seems a bit non-descriptive, I think the term "connectivity" (taken from
the description below) would be clearer.

[Aleksey Shlyapnikov, 2015-10-09 21:02:51]

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
File chrome/common/chrome_switches.cc (right):

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
chrome/common/chrome_switches.cc:319: "default-printer-selection-rules";
On 2015/10/09 16:35:47, Thiemo Nagel wrote:
> Adding command line switches is not allowed unless there's a good reason for
it.

My rationale was to offer non-enterprise users unhappy with default printer
policy a way to address it.
Actually, was it a request to remove this command line switch or to explain it?

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4113: 'name':
'PrintPreviewDefaultPrinterSelection',
On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> Why not just DefaultPrinterSelection?

In most other places settings and switches for PrintPreview are prefixed so. I
can drop it here, if you think it's a better practice.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4116: 'supported_on':
['chrome.*:47-', 'chrome_os:47-'],
On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> 47 has sailed.  Please change to 48.

Done.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4121: 'example_value': '{
"kind": "cloud", "namePattern": ".*Color" }',
On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> Please include an idPattern in the example, too.

I'd imagine that in most cases you either match by a name or id, not both at the
same time, but ok. Done.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4124: 'desc': '''Overrides <ph
name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> Print Preview default printer
selection rules.
On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> How about:
> 
> This policy determines the rules for selecting the default printer in <ph
> name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> which happens the first time
> the print function is used with a profile.
> 
> (I'd suggest to avoid the term "Print Preview" because users may not know what
> it means.  Probably to them it is just "printing".  Also the headline of the
> print preview page is just "Print".)

Done.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4128: When this policy is set,
Print Preview will attempt to find a printer matching the specified attributes,
printer type, printer id or name patterns, and select it as the current one.
On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> Please be more precise about how the final condition is assembled.  (I'm
> guessing "kind && (idPattern || namePattern)" but this is not very clear from
> the description.)

It's "matching the _specified_ attributes", that is kind && idPattern &&
namePattern. There is no || condition. If you skip it, we won't care about it.
That's why I did not want to add isPattern to the example, to make it more
obvious that any part can be omitted.

> 
> To be clearer:
> "select it as the current one" --> "select it as default printer"

Done to this part.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4136: "kind": {
On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> "kind" seems a bit non-descriptive, I think the term "connectivity" (taken
from
> the description below) would be clearer.

local includes, for example, printers provided by extensions, which is not as
easy to mentally map to 'connectivity'.

[Thiemo Nagel, 2015-10-12 19:10:09]

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
File chrome/common/chrome_switches.cc (right):

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
chrome/common/chrome_switches.cc:319: "default-printer-selection-rules";
> My rationale was to offer non-enterprise users unhappy with default printer
> policy a way to address it.
> Actually, was it a request to remove this command line switch or to explain
it?

I guess the request was to remove the flag unless there's a very good reason to
have it, for a discussion on removing command line switches, cf.:

https://groups.google.com/a/chromium.org/d/topic/chromium-dev/8EjjXUoFqMI/dis...

I believe that allowing users better control is not a good justification for
adding a command line flag.  If a setting is not important enough to make it
into chrome://settings, it shouldn't exist at all.  At least that's my
understanding of Chrome philosophy.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4113: 'name':
'PrintPreviewDefaultPrinterSelection',
On 2015/10/09 21:02:51, Aleksey Shlyapnikov wrote:
> On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> > Why not just DefaultPrinterSelection?
> 
> In most other places settings and switches for PrintPreview are prefixed so. I
> can drop it here, if you think it's a better practice.

I think dropping the PrintPreview is easier for users (in this case admins) to
understand, thus I'd be in favour of that.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4121: 'example_value': '{
"kind": "cloud", "namePattern": ".*Color" }',
On 2015/10/09 21:02:51, Aleksey Shlyapnikov wrote:
> On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> > Please include an idPattern in the example, too.
> 
> I'd imagine that in most cases you either match by a name or id, not both at
the
> same time, but ok. Done.

I see.  What is a printer id, anyways?  I was expecting something like
"lc0zeudhs2wlw4ekqtvbjg" but that doesn't seem to be the case?

https://codereview.chromium.org/1368013004/diff/80001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/80001/components/policy/resou...
components/policy/resources/policy_templates.json:4128: When this policy is set,
<ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> will attempt to find a
printer matching the specified attributes, printer type, printer id and name
pattern, and select it as default printer.
I think this would be clearer if the attributes weren't listed again, eg.:

"matching the specified attributes, printer type, printer id and name pattern,"
--> "matching all of the specified attributes"

BTW: What happens if the match is non-unique?  Which printer will be selected in
that case?  And what if there is no match?

[Aleksey Shlyapnikov, 2015-10-13 18:14:57]

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
File chrome/common/chrome_switches.cc (right):

https://codereview.chromium.org/1368013004/diff/40001/chrome/common/chrome_sw...
chrome/common/chrome_switches.cc:319: "default-printer-selection-rules";
On 2015/10/12 19:10:09, Thiemo Nagel wrote:
> > My rationale was to offer non-enterprise users unhappy with default printer
> > policy a way to address it.
> > Actually, was it a request to remove this command line switch or to explain
> it?
> 
> I guess the request was to remove the flag unless there's a very good reason
to
> have it, for a discussion on removing command line switches, cf.:
> 
>
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/8EjjXUoFqMI/dis...
> 
> I believe that allowing users better control is not a good justification for
> adding a command line flag.  If a setting is not important enough to make it
> into chrome://settings, it shouldn't exist at all.  At least that's my
> understanding of Chrome philosophy.

Done.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4113: 'name':
'PrintPreviewDefaultPrinterSelection',
On 2015/10/12 19:10:09, Thiemo Nagel wrote:
> On 2015/10/09 21:02:51, Aleksey Shlyapnikov wrote:
> > On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> > > Why not just DefaultPrinterSelection?
> > 
> > In most other places settings and switches for PrintPreview are prefixed so.
I
> > can drop it here, if you think it's a better practice.
> 
> I think dropping the PrintPreview is easier for users (in this case admins) to
> understand, thus I'd be in favour of that.

Done.

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4121: 'example_value': '{
"kind": "cloud", "namePattern": ".*Color" }',
On 2015/10/12 19:10:09, Thiemo Nagel wrote:
> On 2015/10/09 21:02:51, Aleksey Shlyapnikov wrote:
> > On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> > > Please include an idPattern in the example, too.
> > 
> > I'd imagine that in most cases you either match by a name or id, not both at
> the
> > same time, but ok. Done.
> 
> I see.  What is a printer id, anyways?  I was expecting something like
> "lc0zeudhs2wlw4ekqtvbjg" but that doesn't seem to be the case?

It depends. For cloud printers that would be the case, some generated id or
GUID, for local printers it will most likely be the same as printer name, for
Privet printers it is provided by the printer, unless it is registered with the
cloud too.
id is more useful for cloud printers, name is a better choice for other types,
but then, if your cloud printer is re-registered often (that is, its id
changes), name match might work here too. So, as I said, it depends.

https://codereview.chromium.org/1368013004/diff/80001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/80001/components/policy/resou...
components/policy/resources/policy_templates.json:4128: When this policy is set,
<ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> will attempt to find a
printer matching the specified attributes, printer type, printer id and name
pattern, and select it as default printer.
On 2015/10/12 19:10:09, Thiemo Nagel wrote:
> I think this would be clearer if the attributes weren't listed again, eg.:
> 
> "matching the specified attributes, printer type, printer id and name
pattern,"
> --> "matching all of the specified attributes"
> 
> BTW: What happens if the match is non-unique?  Which printer will be selected
in
> that case?  And what if there is no match?

Thank you for pointing that out, mentioned these cases too. Done.

[Thiemo Nagel, 2015-10-15 15:31:52]

policy_templates.json LGTM with optional nits

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4121: 'example_value': '{
"kind": "cloud", "namePattern": ".*Color" }',
On 2015/10/13 18:14:57, Aleksey Shlyapnikov wrote:
> On 2015/10/12 19:10:09, Thiemo Nagel wrote:
> > On 2015/10/09 21:02:51, Aleksey Shlyapnikov wrote:
> > > On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> > > > Please include an idPattern in the example, too.
> > > 
> > > I'd imagine that in most cases you either match by a name or id, not both
at
> > the
> > > same time, but ok. Done.
> > 
> > I see.  What is a printer id, anyways?  I was expecting something like
> > "lc0zeudhs2wlw4ekqtvbjg" but that doesn't seem to be the case?
> 
> It depends. For cloud printers that would be the case, some generated id or
> GUID, for local printers it will most likely be the same as printer name, for
> Privet printers it is provided by the printer, unless it is registered with
the
> cloud too.
> id is more useful for cloud printers, name is a better choice for other types,
> but then, if your cloud printer is re-registered often (that is, its id
> changes), name match might work here too. So, as I said, it depends.

Thanks a lot for the explanation!

Nit: Thinking about this some more: Since you say it doesn't make a lot of sense
to specify name AND idPattern, would it not be useful to change the logic to
look for name OR idPattern?

https://codereview.chromium.org/1368013004/diff/100001/components/policy/reso...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/100001/components/policy/reso...
components/policy/resources/policy_templates.json:4156: Regular expression
patterns are case sensistive.''',
Nit: There are many regular expression libraries/standards that differ
significantly between each other. Would it be possible to mention which one
you're using or link to a description of the syntax?

[Aleksey Shlyapnikov, 2015-10-15 22:12:40]

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/40001/components/policy/resou...
components/policy/resources/policy_templates.json:4121: 'example_value': '{
"kind": "cloud", "namePattern": ".*Color" }',
On 2015/10/15 15:31:51, Thiemo Nagel wrote:
> On 2015/10/13 18:14:57, Aleksey Shlyapnikov wrote:
> > On 2015/10/12 19:10:09, Thiemo Nagel wrote:
> > > On 2015/10/09 21:02:51, Aleksey Shlyapnikov wrote:
> > > > On 2015/10/09 16:35:48, Thiemo Nagel wrote:
> > > > > Please include an idPattern in the example, too.
> > > > 
> > > > I'd imagine that in most cases you either match by a name or id, not
both
> at
> > > the
> > > > same time, but ok. Done.
> > > 
> > > I see.  What is a printer id, anyways?  I was expecting something like
> > > "lc0zeudhs2wlw4ekqtvbjg" but that doesn't seem to be the case?
> > 
> > It depends. For cloud printers that would be the case, some generated id or
> > GUID, for local printers it will most likely be the same as printer name,
for
> > Privet printers it is provided by the printer, unless it is registered with
> the
> > cloud too.
> > id is more useful for cloud printers, name is a better choice for other
types,
> > but then, if your cloud printer is re-registered often (that is, its id
> > changes), name match might work here too. So, as I said, it depends.
> 
> Thanks a lot for the explanation!
> 
> Nit: Thinking about this some more: Since you say it doesn't make a lot of
sense
> to specify name AND idPattern, would it not be useful to change the logic to
> look for name OR idPattern?

There're three fields and kind is always joined by AND with the rest. I think
it's more logical to join them all by AND. I'd wait for a feed back and extend
the policy with more features, should there's a demand for more.

https://codereview.chromium.org/1368013004/diff/100001/components/policy/reso...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/1368013004/diff/100001/components/policy/reso...
components/policy/resources/policy_templates.json:4156: Regular expression
patterns are case sensistive.''',
On 2015/10/15 15:31:51, Thiemo Nagel wrote:
> Nit: There are many regular expression libraries/standards that differ
> significantly between each other. Would it be possible to mention which one
> you're using or link to a description of the syntax?

Done.

[Andrew T Wilson (Slow), 2015-10-16 10:40:24]

owner LGTM

[Aleksey Shlyapnikov, 2015-10-16 18:36:08]

The CQ bit was checked by alekseys@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-16 18:37:17]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/120001

[commit-bot: I haz the power, 2015-10-16 18:43:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-16 18:43:55]

Dry run: Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

[Aleksey Shlyapnikov, 2015-10-16 20:00:18]

The CQ bit was checked by alekseys@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-16 20:01:11]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/140001

[commit-bot: I haz the power, 2015-10-16 21:08:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-16 21:08:38]

Dry run: This issue passed the CQ dry run.

[Aleksey Shlyapnikov, 2015-10-16 21:21:58]

The CQ bit was checked by alekseys@chromium.org

[Aleksey Shlyapnikov, 2015-10-16 21:21:58]

The patchset sent to the CQ was uploaded after l-g-t-m from
vitalybuka@chromium.org, cawarren@chromium.org, erg@chromium.org,
asvitkine@chromium.org, gab@chromium.org, tnagel@chromium.org,
atwilson@chromium.org
Link to the patchset: https://codereview.chromium.org/1368013004/#ps140001
(title: "Add tags to DefaultPrinterSelection policy.")

[commit-bot: I haz the power, 2015-10-16 21:22:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1368013004/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1368013004/140001

[commit-bot: I haz the power, 2015-10-16 21:28:55]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2015-10-16 21:29:49]

Patchset 8 (id:??) landed as
https://crrev.com/4b26916d54c1068cd7e67ecdcdd03f36ebc23dcf
Cr-Commit-Position: refs/heads/master@{#354604}