provide LP developers full access to QAS/Staging feature flags
Bug #790025 reported by
Steve McInerney
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Unassigned |
Bug Description
Currently LP Devs must losa pingaling to modify/add feature rules in staging/qas.
Given we now have an automatic audit/change log for those rules, it may be appropriate to have some mechanism in the restore process that can set the Devs to have full rules access - for staging/qas only.
Along the lines of some SQL that could be run that toggles privilege to a specific group - in this case, LP devs.
Related branches
lp:~mbp/launchpad/feature-admin-party
Rejected
for merging
into
lp:launchpad
- Launchpad code reviewers: Pending requested
-
Diff: 258 lines (+83/-31)6 files modifiedlib/canonical/launchpad/pagetests/basics/demo-and-lpnet.txt (+4/-11)
lib/lp/registry/browser/tests/test_product.py (+4/-4)
lib/lp/services/features/browser/configure.zcml (+6/-3)
lib/lp/services/features/browser/edit.py (+15/-2)
lib/lp/services/features/browser/tests/test_feature_editor.py (+35/-11)
lib/lp/testing/fixture.py (+19/-0)
tags: | added: canonical-losa-lp feature feature-flags |
To post a comment you must log in.
Theres no current policy knob for who-can-edit other than 'in ~admin' which would be inappropriate.
What we could do is add one and then put ~launchpad in it when desired.
One way would be to create a different group to ~admins which controls access and then put ~admin in that. The sync to qastaging would make an API call post-sync to add ~launchpad.
Another would be to explicitly model an access list of some sort.