Nominally, radix has permission to view the former branch, because he's a member of Launchpad Hackers via Landscape (those playing at home might want to look at query 33 in the SQL Statement Log.). But radix does *not* have permission to view the latter branch -- the stacked-on branch -- for reasons that elude me. Our security code checks the visibility of the stacked-on branch when checking the visibility of a stacked branch and boom!
The underlying bug is that IBranchCollection.visibleByUser is returning false positives, branches that the user cannot see. Possible fixes include:
- changing visibleByUser to filter out branches with invisible stacked-on branches
- change our security policy somehow so that stacked-on branch visibility doesn't need to be checked.
Tim, it's probably a little ambitious to assign this to the current milestone without assigning it to someone.
I've taken a look at the OOPS. The lists of branches displayed on the front page are already filtered for user visibility, but...
... you'll love this...
lp:~allenap/launchpad/api-create-bug-mail-bug-373174 is stacked on lp:~launchpad-pqm/launchpad/db-devel
Nominally, radix has permission to view the former branch, because he's a member of Launchpad Hackers via Landscape (those playing at home might want to look at query 33 in the SQL Statement Log.). But radix does *not* have permission to view the latter branch -- the stacked-on branch -- for reasons that elude me. Our security code checks the visibility of the stacked-on branch when checking the visibility of a stacked branch and boom!
The underlying bug is that IBranchCollecti on.visibleByUse r is returning false positives, branches that the user cannot see. Possible fixes include:
- changing visibleByUser to filter out branches with invisible stacked-on branches
- change our security policy somehow so that stacked-on branch visibility doesn't need to be checked.
The workaround for radix and cr3 is probably just to subscribe them to the lp:~launchpad-pqm/launchpad/db-devel branch.