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._set_information_type ensures that the appropriate access policy exists for the product's information type. That's why I wrote "It appears that the case where information_type is changed is already covered" in the bug. I'd be very interested if you can demonstrate otherwise.
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. -- https://code.launchpad.net/~abentley/launchpad/info-type-adds-policy/+merge/132749 Your team Launchpad code reviewers is requested to review the proposed merge of lp:~abentley/launchpad/info-type-adds-policy into lp:launchpad. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-reviewers Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-reviewers More help : https://help.launchpad.net/ListHelp
