Merge lp://staging/~gary/launchpad/bug777874 into lp://staging/launchpad

[r=gmb][bug=777874] enable autocompletion of "New" bugtasks that affect more than one person. Feature-flagged by project/distro.

This branch fixes bug 777874 by enabling autoconfirmation of new bugtasks that affect more than one person. It is feature-flagged by project and distribution, though the intent is to roll it out to all Launchpad users.

The discussion in the bug, particularly in comment 11 (https://bugs.launchpad.net/launchpad/+bug/777874/comments/11) is a good background to what I'm doing. The only difference is that I ended up not using events. The call sites were very constrained, and generic modified events would have been more difficult that what I actually needed. gmb was fine with this on a follow-up conversation.

The Python is well tested.

The JavaScript was within a completely untested module, and I did not try to add tests. Moreover, this is the kind of use case that calls out for a client-side MVC pattern. We just don't have it yet.

Tests can be run with
./bin/test -vv lp.bugs.model.tests.test_bug TestBugAutoConfirmation
and
./bin/test -vv lp.bugs.model.tests.test_bugtask TestAutoConfirmBugTasks

I get layer teardown errors when I do this, but it has nothing to do with my branch's changes to my knowledge. I think it is something to do with running tests from a single layer, but I didn't dig into it past a cursory investigation.

  File "/home/gary/launchpad/lp-branches/bug777874/lib/canonical/testing/layers.py", line 363, in tearDown
    cls.fixture.cleanUp()
AttributeError: 'NoneType' object has no attribute 'cleanUp'

Lint is happy.

I am a bit paranoid that privacy issues will bite this code somehow (e.g., the current user does not have privileges to change the status of a bug and things fall over when they try to set a dupe or say "me too"), but I can't think of a way: the calls I make are either internal to an object, and so not wrapped with a security proxy; or they are publicly allowed. I'd appreciate your consideration of this issue in the review though.

QA/testing:

I'll define two scenarios, then describe what to do with them.

Scenario 1:
 A. Go to or make a bug that has a bugtask in a NEW status and only one person affected (but at least one--launchpad.dev has some that are don't affect anyone to start with, like its bug 1) who is not you.
 B. Mark the bug as affecting you.

Scenario 2:
 A. Go to or make a bug that has a bugtask in a NEW status and only one person affected (but at least one--launchpad.dev has some that are don't affect anyone to start with, like its bug 1) who is not you.
 B. Go to another bug and mark it as a duplicate of the first bug.
 C. Return to the first bug.

Scenario 3:
 A. Go to or make a bug that has a bugtask in a NEW status and that *only affects you*.
 B. Go to another bug and mark it as a duplicate of the first bug.
 C. Return to the first bug.

First, verify that, without feature flags set, there is no autoconfirm for all three scenarios.

Now set feature flags to turn on the behavior for ubuntu and launchpad. Locally, that means that you go to https://launchpad.dev/+feature-rules . You want these rules.

bugs.autoconfirm.enabled_distribution_names default 1 ubuntu
bugs.autoconfirm.enabled_product_names default 1 launchpad

Now, go through scenarios 1 and 2 for ubuntu and/or launchpad-related bugs and make sure that bugtasks change; and go through scenarios 1 and 2 for other projects and/or distributions and make sure they do not change. Finally, if you want, go through scenario 3 for ubuntu/launchpad and make sure that bugtasks do *not* change.

For extra credit, change the flags to match everything:

bugs.autoconfirm.enabled_distribution_names default 1 *
bugs.autoconfirm.enabled_product_names default 1 *

Now make sure that scenarios 1 and 2 make a change, and 3 does not.

Writing this, it strikes me that distribution names and product names share a namespace, so I didn't need to separate them. I'm not inclined to change anything, but I could if you wanted. It would make the code that we plan to delete anyway a bit simpler.

Thank you!

Gary