Merge lp:~wgrant/launchpad/observer-db into lp:launchpad/db-devel
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | William Grant | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 11151 | ||||
Proposed branch: | lp:~wgrant/launchpad/observer-db | ||||
Merge into: | lp:launchpad/db-devel | ||||
Prerequisite: | lp:launchpad | ||||
Diff against target: |
97 lines (+82/-0) 2 files modified
database/schema/comments.sql (+23/-0) database/schema/patch-2208-93-1.sql (+59/-0) |
||||
To merge this branch: | bzr merge lp:~wgrant/launchpad/observer-db | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins (community) | Approve | ||
Stuart Bishop (community) | db | Approve | |
Review via email: mp+81104@code.launchpad.net |
This proposal supersedes a proposal from 2011-11-03.
Commit message
[r=lifeless,stub][bug=890931] First part of the AccessPolicy DB model.
Description of the change
This is the initial DB patch for Disclosure's access policies. The migration process will be long and tortuous, but this is a start.
A private artifact (currently a bug or a branch) will be linked to one of its target's access policies, and attempts to access the artifact will be checked against the policy's permissions. This will shortly supplant the existing subscription-
Permissions can be either policy-global or artifact-specific. In the first case APP.artifact is left unset, letting the permission holder see all artifacts under the policy. For the second case both policy and artifact are set, restricting the access to a specific artifact under a specific policy.
The identification of access policies isn't well-defined yet, but this schema will do for now. The intent is that, at least for the initial pass, projects will have preconfigured and immutable "Private" and "Security" policies, with the existing bug privacy/security checkboxes altered to map onto these policies. So we either have to use an enum, or just treat these as well-known names until a later pass.
I think s/Permission/Grant/ will avoid some confusion.
This looks like what we discussed. Cool. Worth nothing I think is some more intent.
E.g. for artifacts mention that more types should be added there rather than in parallel tables.
Stuart: the idea here is that reporting is simple: one table supplies all the grants made to a private project/distro. Rather than a constantly evolving set of unions, this provides a single (indirect) level in the DB : *and* lets us query and report grants without accessing the granted-on objects [at least at this point]).
+1 from me but please get Stuarts ok before landing.