Opened on 10/21/2014 at 12:32:00 PM

Closed on 03/20/2015 at 02:41:38 PM

#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@adblockplus.org, 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.

Attachments (0)

Change History (20)

comment:1 Changed on 10/21/2014 at 12:46:21 PM by mapx

  • Cc mapx added

comment:2 Changed on 10/21/2014 at 01:49:53 PM by sebastian

  • Blocking 1488 added

comment:3 Changed on 10/21/2014 at 01:53:13 PM by sebastian

  • Blocking 1489 added

comment:4 Changed on 10/21/2014 at 01:54:02 PM by sebastian

  • Blocking 206 removed

comment:5 Changed on 10/21/2014 at 02:04:10 PM by sebastian

  • Blocking 278 removed

comment:6 Changed on 10/21/2014 at 02:16:48 PM by sebastian

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

comment:7 Changed on 10/21/2014 at 02:30:26 PM by sebastian

  • Blocking 1490 added

comment:8 Changed on 10/21/2014 at 03:08:53 PM by sebastian

  • Description modified (diff)

comment:9 Changed on 10/21/2014 at 03:40:57 PM by sebastian

  • Description modified (diff)

comment:10 Changed on 10/21/2014 at 03:41:51 PM by sebastian

  • Description modified (diff)

comment:11 in reply to: ↑ description ; follow-up: Changed on 10/21/2014 at 05:04:32 PM 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 on 10/21/2014 at 05:23:04 PM 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 on 10/22/2014 at 12:39:15 AM by oleksandr

  • Cc oleksandr@adblockplus.org added

comment:14 Changed on 10/22/2014 at 11:32:51 AM by sebastian

  • Cc sebastian removed

comment:15 Changed on 10/27/2014 at 04:37:32 PM by sebastian

  • Description modified (diff)

comment:16 Changed on 10/30/2014 at 01:06:37 PM by simona

  • Keywords growth added

comment:17 Changed on 11/21/2014 at 11:53:48 AM by simona

  • Cc simona added

comment:18 Changed on 11/21/2014 at 04:20:35 PM by simona

  • Keywords large-scale-deployments added

comment:19 Changed on 03/20/2015 at 02:21:00 PM by sebastian

  • Blocking 1488 removed

comment:20 Changed on 03/20/2015 at 02:41:38 PM 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.

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
 
Note: See TracTickets for help on using tickets.