Merge lp:~deryck/launchpad/top-level-bug-search-and-privacy-1069895 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Deryck Hodge on 2012-11-13 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 16275 |
| Proposed branch: | lp:~deryck/launchpad/top-level-bug-search-and-privacy-1069895 |
| Merge into: | lp:launchpad |
| Diff against target: |
226 lines (+70/-18) 6 files modified
lib/lp/bugs/browser/tests/test_bugs.py (+34/-4) lib/lp/bugs/browser/tests/test_bugtask.py (+5/-5) lib/lp/bugs/model/bugtasksearch.py (+17/-1) lib/lp/registry/browser/tests/test_milestone.py (+6/-6) lib/lp/registry/browser/tests/test_pillar_sharing.py (+1/-1) lib/lp/registry/model/product.py (+7/-1) |
| To merge this branch: | bzr merge lp:~deryck/launchpad/top-level-bug-search-and-privacy-1069895 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Richard Harding (community) | 2012-11-13 | Approve on 2012-11-13 | |
|
Review via email:
|
|||
Commit Message
Ensure that bugtask search accounts for whether or not any related products are private, which will keep the top-level bugs homepage from erroring out if there are any public bugs against proprietary or embargoed projects.
Description of the Change
This branch fixes bug 1069895 by ensuring that any bugtask search results that is a mix of public bugs with those that have private projects will exclude bugs with private projects. This is kind of an odd situation to be in and we have other work in progress to prevent public bugs on proprietary projects but this fix will make sure we don't error (especially on the top-level bugs homepage) if we get into this kind of mixed data situation.
The fix is pretty straight forward. It amounts to updating the bugtask search query to account for private projects. There is also a test to ensure the specific condition we want to avoid is safe. Finally, a handful of bugtask search query count tests had to be updated. I'm honestly at a loss for how these counts could change, given that I'm adding a join to an existing query. I was worried that maybe I was returning more data than originally and some loop over the data was doing extra queries. But some of these tests here even assert that the expected number of bugtasks are returned, and that the size of the queries doesn't change as more data is added.
So I'm not sure what's up here, but it should be safe, given that it's only adding a query or two in each case.
| Deryck Hodge (deryck) wrote : | # |
Thanks for the review. #58/59 is a mistake. It's a hold over from an earlier version of the test. I'll drop that line. Good catch!
And #141, yes, you can indeed have a bugtask without a product. It can be against a distro source package, the distro itself, and so on. Any context other than a product wouldn't have a product.

#58/59
Do you mean to be asserting that the factory is working by checking the information type/title on bug?
I thought in the stand up it was brought that the the query counts should be exact so that you can know when you changed/broke something that reduced the query count as well. This appears to continue using the 'less than' approach.
#141
For my FYI: can we have a bugtask without a product? This struck me as odd.