Opened 5 years ago

Closed 5 years ago

#1487 closed change (incomplete)

Enable pre-configurable properties

Reported by: sebastian Assignee:
Priority: P3 Milestone:
Module: Core Keywords: growth, large-scale-deployments
Cc: trev, philll, mapx, oleksandr@…, simona Blocked By:
Blocking: Platform: Unknown
Ready: no Confidential: no
Tester: Verified working: no
Review URL(s):

Description (last modified by sebastian)

Background

To help administrators deploying Adblock Plus in managed networks, we have to make some options pre-configurable. On Firefox and IE we can just read the pre-configured options from a file on the disk. On Chrome, however we have to use the Managed Storage API.

What to change

Implement a mechanism in the core code to support pre-configured properties. Provide hooks for the platform-specific implementation to retrieve those properties, considering that those hooks have to be implemented with asynchronous APIs (on some platforms, e.g. Chrome). However, since some platforms (i.e. Opera, Safari, Android) won't support pre-configurable properties those hooks must be optional.

Pre-configured properties should be accessed the same way as user-defined properties via prefs.Prefs. However, there must be a whitelist restricting the properties that can be pre-configured, for now that will be only hide_first_run_page. Also if there is a user-defined property with the same name, the value set by the user must override the pre-configured value.

Change History (20)

comment:1 Changed 5 years ago by mapx

  • Cc mapx added

comment:2 Changed 5 years ago by sebastian

  • Blocking 1488 added

comment:3 Changed 5 years ago by sebastian

  • Blocking 1489 added

comment:4 Changed 5 years ago by sebastian

  • Blocking 206 removed

comment:5 Changed 5 years ago by sebastian

  • Blocking 278 removed

comment:6 Changed 5 years ago by sebastian

  • Summary changed from Enable pre-configured properties to Enable pre-configurable properties

comment:7 Changed 5 years ago by sebastian

  • Blocking 1490 added

comment:8 Changed 5 years ago by sebastian

  • Description modified (diff)

comment:9 Changed 5 years ago by sebastian

  • Description modified (diff)

comment:10 Changed 5 years ago by sebastian

  • Description modified (diff)

comment:11 in reply to: ↑ description ; follow-up: Changed 5 years ago by trev

Replying to sebastian:

Pre-configured properties should be accessed the same way as user-defined properties via prefs.Prefs.

The problem with that: we definitely don't want to allow preconfiguring all preferences we have. That would allow essentially breaking parts of Adblock Plus functionality for the users - something that they will blame us for, not their admins. Things like documentation_link or report_submiturl prefs shouldn't be configured by admins.

On the other hand, using Prefs has the advantage that users can still override admin settings. But we would need a whitelist with prefs that can be pre-configured.

comment:12 in reply to: ↑ 11 Changed 5 years ago by sebastian

Replying to trev:

Replying to sebastian:

Pre-configured properties should be accessed the same way as user-defined properties via prefs.Prefs.

The problem with that: we definitely don't want to allow preconfiguring all preferences we have. That would allow essentially breaking parts of Adblock Plus functionality for the users - something that they will blame us for, not their admins. Things like documentation_link or report_submiturl prefs shouldn't be configured by admins.

On Chrome we have to provide a schema (white-)listing the pre-configurable properties. But yeah, good point, on Firefox and IE admins could still pre-configure any preference. We definitely should prevent that. In order to do that we could just check whether the pre-configured option is in a whitelist. What do you think?

On the other hand, using Prefs has the advantage that users can still override admin settings. But we would need a whitelist with prefs that can be pre-configured.

Absolutely, that is why I suggested that approach in the first place.

comment:13 Changed 5 years ago by oleksandr

  • Cc oleksandr@… added

comment:14 Changed 5 years ago by sebastian

  • Cc sebastian removed

comment:15 Changed 5 years ago by sebastian

  • Description modified (diff)

comment:16 Changed 5 years ago by simona

  • Keywords growth added

comment:17 Changed 5 years ago by simona

  • Cc simona added

comment:18 Changed 5 years ago by simona

  • Keywords large-scale-deployments added

comment:19 Changed 5 years ago by sebastian

  • Blocking 1488 removed

comment:20 Changed 5 years ago by sebastian

  • Blocking 542, 1489, 1490 removed
  • Ready unset
  • Resolution set to incomplete
  • Status changed from new to closed

Apparently, we implement preferences differently on all platforms. So there is no need or way to support pre-configurable preferences in the core code. We might still want to have a common list of pre-configurable preferences in the future. But for now, we decided to have them listed only in the Managed Storage Schema for Chrome. And if needed we could just use the same file also on other platforms.

Note: See TracTickets for help on using tickets.