Merge lp:~abentley/launchpad/info-type-adds-policy into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Aaron Bentley on 2012-11-05 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 16234 |
| Proposed branch: | lp:~abentley/launchpad/info-type-adds-policy |
| Merge into: | lp:launchpad |
| Diff against target: |
58 lines (+19/-3) 2 files modified
lib/lp/registry/model/product.py (+1/-0) lib/lp/registry/tests/test_product.py (+18/-3) |
| To merge this branch: | bzr merge lp:~abentley/launchpad/info-type-adds-policy |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Benji York (community) | code | 2012-11-02 | Approve on 2012-11-05 |
|
Review via email:
|
|||
Commit Message
Product information_type access policy is retained.
Description of the Change
= Summary =
Fix bug #1074139: Setting policies different from project information_type locks the owner out
== Proposed fix ==
Update Product.
== Pre-implementation notes ==
None
== LOC Rationale ==
Part of private products.
== Implementation details ==
Cleaned up some lint as a driveby.
== Tests ==
bin/test -t test_informatio
== Demo and Q/A ==
Create a Proprietary product. Change all the sharing policies to Public. You should still be able to see the product, and you should be listed under Proprietary.
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
| Curtis Hovey (sinzui) wrote : | # |
| Aaron Bentley (abentley) wrote : | # |
Curtis, I started off with the assumption that making a public project proprietary could cause this bug, but I was unable to write a test case demonstrating this, because Product.
I attempted to get more information from cr3, but he did not respond on IRC. So I proceeded with the assumption that the cause of the bug was different from what we originally supposed-- that changing the access policies, not changing the information type, had locked the user out.
I know you feel that privacy should be transitive, but that's orthagonal to this bug, because this bug can be exhibited even when no elements are public. As I noted in the bug: "However, there is another case: the project is Embargoed and the sharing policies are all proprietary. This situation would not be forbidden by Curtis's rule."
So let's keep this bug being about the fact that the maintainer can be locked out of their own product. Please file a separate bug for the lack of transitivity between Product and its policies. Deryck and I do not agree with you on that matter, but AIUI Deryck plans to discuss it with you.
| Benji York (benji) wrote : | # |
Thanks for the branch. Everything looks good to me.

I am surprised this fixes the issue. cr3 had a Public project, then made it Proprietary using +edit; he was locked out. I looked at the project and discovered 2 things wrong.
1. The sharing policies where not updated to reflect the transitive state of the project...the sharing policies were not changed to Proprietary.
2. Proprietary was not shared with the Maintainer.
I change a policy to proprietary, which automatically shared shared all proprietary with the maintainer, which restored cr3's access to the project. I then set the other sharing policies to Proprietary only.
LATER, cr3 made some sharing polices Public, but he was not locked out since Proprietary was still shared. I changed the Polices back to Proprietary because though Bugs and Blueprints could claimed to be public, they cannot be because privacy is transitive; staking a Public branch on a Proprietary branch is possible, but the branch will become Proprietary. A bug cannot really be public because the project/bug is not shared with the 1 million Lp users, and you cannot share any public information type.