Merge lp:~wgrant/launchpad/rework-bug-default-type-0 into lp:launchpad
Status: | Merged |
---|---|
Merged at revision: | 15724 |
Proposed branch: | lp:~wgrant/launchpad/rework-bug-default-type-0 |
Merge into: | lp:launchpad |
Diff against target: |
161 lines (+32/-30) 6 files modified
lib/lp/bugs/browser/bugtarget.py (+7/-12) lib/lp/bugs/interfaces/bug.py (+4/-4) lib/lp/bugs/mail/commands.py (+12/-7) lib/lp/bugs/model/bug.py (+4/-2) lib/lp/bugs/xmlrpc/bug.py (+1/-1) lib/lp/testing/factory.py (+4/-4) |
To merge this branch: | bzr merge lp:~wgrant/launchpad/rework-bug-default-type-0 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Richard Harding (community) | Approve | ||
Review via email: mp+117378@code.launchpad.net |
Commit message
Fix bug creation defaults pretty much everywhere to not be InformationType
Description of the change
This branch is the first in a series of maybe four to rework bug information type defaults, which will eventually allow us to default to Proprietary when a project is so configured.
The web, mail, and XML-RPC interfaces each had their own special variety of manually overriding information types when creating bugs. And they all tended to set it to PUBLIC when the overrides didn't apply, rather than leaving it for the core createBug API to figure out what it should be. This led to createBug containing this wonderful piece of logic:
if params.product and params.
# If the private_bugs flag is set on a product, then
# force the new bug report to be private.
if params.
"You wanted it public? Ha, I know better! Even if you are the bug supervisor and explicitly selected Public."
I've changed default through most of the code to None. createBug understands None to mean that the target's default should be used -- currently Private if private_bugs is set and Public otherwise, but soon to be a little more complex than that. View code that wants to override it in some circumstances (eg. because apport has asked for something to be private, or the user has selected the "This bug is a security vulnerability" checkbox) sets it explicitly, but otherwise leaves it None.
FileBugViewBase is still a little messy, but rework-