| Summary: | [settings] Server admin cannot change default value of individual plugin setting | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Michael_Rennie |
| Version: | 5.0 | ||
| Target Milestone: | 6.0 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
Forgot to close this bug. It was fixed by this commit. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=1857720 The upshot is that the admin can now put something like this in the defaults.pref > "/cm/configurations": { > "eslint.config": { > "validate_no_undef": 0 > } > } .. and 0 will be correctly recognized as the default value of the validate_no_undef attribute of PID eslint.config |
We ran into a case where the server admin wants to provide a default value for an individual plugin setting. In this case the setting is "Flag undefined member use" from ESLint (in other words attribute "validate_no_undef" of PID "eslint.config") For example, the admin wants to add this in the site's defaults.pref to achieve a default value of 0 for validate_no_undef: > "/cm/configurations": { > "eslint.config": { > "validate_no_undef": 0 > } > } there are 2 problems with this approach as it stands i) The default value of 'validate_no_undef' is declared by the contributing plugin as 2, although the administrator has changed the effective value to 0. When the Settings UI handles a user change to the setting, it will believe the default value to be 2, which can cause the value displayed in the UI to become out of sync with the actual value of the setting. ii) If the user has ever gone to the Settings page and changed a plugin setting, the user has a "/local/cm/configurations" key that takes priority over the "/default/cm/configurations" key specified by the admin. They will never observe the new default value of validate_no_undef set by the administrator. (In the Preferences model, keys are the unit that cascades down from higher-level preference providers. But the plugin settings impl stores many settings under a single key.)