boolean interpretation for feature flags
Bug #719182 reported by
Martin Pool
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Won't Fix
|
High
|
Unassigned |
Bug Description
Many feature flags have boolean effects. However, the infrastructure just sends them back as strings, and the callers have varying interpretations:
* 'on' vs 'off'
* non-empty string vs empty string through Python bool(s)
* 'enabled' vs 'disabled'
The inconsistency is likely to lead to bugs or misconfigurations.
We should instead choose a particular syntax and add an API that will get the value as a boolean, including an API that can be used from TAL.
Changed in launchpad: | |
milestone: | none → 11.01 |
milestone: | 11.01 → 11.03 |
assignee: | nobody → Launchpad Green Squad (green-squad) |
Changed in launchpad: | |
status: | Triaged → In Progress |
assignee: | Launchpad Green Squad (launchpad-green-squad) → Curtis Hovey (sinzui) |
To post a comment you must log in.
One way to do this that might fit cleanly with the registry of them, and with wgrant's recent declaration of a value domain, and that might work well from tal, would be for the default getFeatureFlag to just interpret the string from the database into whatever type is expected.
We could also (perhaps as a separate bug) validate that values entered into the admin ui match what is that expected.
In both cases we need to tolerate unknown flags and just treat them as strings.