Merge lp:~jml/launchpad/drop-special-commercial-permissions into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | William Grant on 2012-05-03 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 15205 |
| Proposed branch: | lp:~jml/launchpad/drop-special-commercial-permissions |
| Merge into: | lp:launchpad |
| Prerequisite: | lp:~jml/launchpad/narrow-commercial-celebrity |
| Diff against target: |
113 lines (+15/-40) 3 files modified
lib/lp/security.py (+0/-8) lib/lp/soyuz/stories/webservice/xx-archive-commercial.txt (+5/-3) lib/lp/soyuz/tests/test_archive_agent.py (+10/-29) |
| To merge this branch: | bzr merge lp:~jml/launchpad/drop-special-commercial-permissions |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Anthony Lenton (community) | 2012-05-01 | Approve on 2012-05-03 | |
| William Grant | code | 2012-05-01 | Approve on 2012-05-02 |
| James Westby (community) | 2012-05-01 | Approve on 2012-05-01 | |
| Richard Harding (community) | code | 2012-05-01 | Approve on 2012-05-01 |
|
Review via email:
|
|||
Commit Message
No more special permissions for commercial archives.
Description of the Change
We've discovered that we don't actually need as much of the permission that being ILaunchpadCeleb
Specifically, we don't actually care if 'commercial' is set on PPAs or not, since software-
You can think of the deleted tests as summarizing what software-
Code-wise this is pretty easy, but there's a relatively high integration risk. Thus, we're going to do integration testing with a demo copy of Launchpad run from EC2, so please don't land this until we give the all clear.
Also, I'd welcome reviews from a broader range of reviewers.
Another 25 deletions of credit, bring us up to 113 + 25 = 138.
Thanks,
jml
| Jonathan Lange (jml) wrote : | # |
I think that got truncated, "I'm going to".
We already have tests that arbitrary users cannot access private archives. I don't think we ought to have tests for non-access for every special user that we can think of – otherwise where does it end?
Thanks for the review!
jml
| James Westby (james-w) wrote : | # |
Hi,
This looks good to me from a code point of view.
Agree about the need for integration testing.
I think that we may also want to audit the current PPAs to make sure that
s-c-a won't lose permissions that it needs to complete sales of something
available in software-center. I'm not exactly sure how we would determine
that though.
Thanks,
James
| William Grant (wgrant) wrote : | # |
https:/
It looks like you can probably now remove in_software_
| Jonathan Lange (jml) wrote : | # |
Thanks everyone. I've triggered an 'ec2 test' run for this and will work with achuni & the MyApps guys to make sure we can get proper QA done.
| Anthony Lenton (elachuni) wrote : | # |
Thanks jml,
We've verified sca is still able to go around its business with this change; the only process change is that we need to ensure the sca user is added to the team that owns the ppa now, so that it is able to create subscriptions. This is a reasonable requirement.
| Jonathan Lange (jml) wrote : | # |
OK, talking to Anthony, it would be better if we land this so that we can QA against staging.
I've added a note to the bug asking to please not mark it as qa-ok without first speaking with Anthony.
Thanks,
jml

Thanks Jonathan, as a reviewer I'd tend to want to keep the check that the user doesn't have access/permissions to the private archive just so that I can be sure 100% that this doesn't enable something that was previously forbidden, but that's just because I'm not all that sure of the full set of possible ramifications.
I'm going to