Merge lp:~danilo/launchpad/proper-bug-muting into lp:launchpad/db-devel
Status: | Merged |
---|---|
Approved by: | Данило Шеган |
Approved revision: | no longer in the source branch. |
Merged at revision: | 10561 |
Proposed branch: | lp:~danilo/launchpad/proper-bug-muting |
Merge into: | lp:launchpad/db-devel |
Diff against target: |
886 lines (+291/-86) 18 files modified
database/schema/comments.sql (+6/-0) database/schema/patch-2208-70-0.sql (+36/-0) database/schema/security.cfg (+2/-0) lib/lp/bugs/browser/bugsubscription.py (+20/-3) lib/lp/bugs/browser/tests/test_bug_context_menu.py (+2/-4) lib/lp/bugs/browser/tests/test_bugsubscription_views.py (+5/-5) lib/lp/bugs/configure.zcml (+7/-0) lib/lp/bugs/interfaces/bug.py (+17/-0) lib/lp/bugs/interfaces/bugnotification.py (+4/-2) lib/lp/bugs/model/bug.py (+62/-22) lib/lp/bugs/model/bugnotification.py (+25/-12) lib/lp/bugs/model/bugsubscriptionfilter.py (+2/-2) lib/lp/bugs/scripts/bugnotification.py (+1/-1) lib/lp/bugs/scripts/tests/test_bugnotification.py (+2/-1) lib/lp/bugs/tests/test_bug.py (+23/-17) lib/lp/bugs/tests/test_bugchanges.py (+22/-7) lib/lp/bugs/tests/test_bugnotification.py (+51/-9) lib/lp/registry/model/person.py (+4/-1) |
To merge this branch: | bzr merge lp:~danilo/launchpad/proper-bug-muting |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Graham Binns (community) | code | Approve | |
Stuart Bishop (community) | db | Approve | |
Robert Collins | db | Pending | |
Review via email: mp+60615@code.launchpad.net |
Commit message
[r=gmb,stub][bug=772763] Use a separate table for muting bug subscriptions to allow restoring one's subscription after unmuting.
Description of the change
= Bug 772763: step 1 =
At the moment, muting a bug is implemented using BugSubscription by setting bug_notificatio
== Proposed fix ==
To parallel BugSubscription
Since we only "expand" subscribers at a very late stage when emails are constructed (in construct_
I wonder if I should do the migration of NOTHING subscriptions to BugMute records in the DB patch or not. That depends on how many of them there are, but it'd probably be best to do it that way.
== Implementation details ==
* We provide a very basic BugMute table that is modelled after the BugSubscription
* XXXes are there to remind me to talk to the team if we really want to log bug muting/unmuting in the bug activity log (assuming bug.addChange does that), as it used to with the use of subscribe/
* We modify getRecipientFil
* Test in test_bugchanges.py is the integration test (interestingly, one that even failed for the existing implementation, because muting didn't work for all cases).
* UI is not modified in any way in this branch, which means that it will be a bit confusing; that's left for follow-up branches.
* Another branch will go on with removing the NOTHING level if possible.
* Some typos in registry/
* I have another 144 diff of lint fixes for mostly things not caused by my changes, not including it so the branch is smaller; similar holds for sampledata updates, I'll commit them after review.
== Tests ==
bin/test -cvvt TestBugSubscrip
== Demo and Q/A ==
With 'malone.
Note that until UI is fully adapted as well, you might need to refresh the page between actions.
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
database/
lib/lp/
database/
lib/lp/
database/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
== Schema ==
database/
database/
Patches to the schema, or manual edits to database/
do not match the dump of the launchpad_
If database/
database/
Otherwise update database/
make schema
make newsampledata
cd database/sampledata
cp newsampledata.sql database/
Run make schema again to update the test/dev database.
database/
database/
Patches to the schema, or manual edits to database/
do not match the dump of the launchpad_
If database/
database/
Otherwise update database/
make schema
make newsampledata
cd database/sampledata
cp newsampledata-
Run make schema again to update the test/dev database.
./lib/lp/
147: local variable 'cached_people' is assigned to but never used
152: local variable 'cached_bugs' is assigned to but never used
273: E501 line too long (81 characters)
192: Line exceeds 78 characters.
273: Line exceeds 78 characters.
./lib/lp/
387: E201 whitespace after '{'
./lib/lp/
175: Line exceeds 78 characters.
./lib/lp/
211: local variable 'bug_subscription' is assigned to but never used
605: local variable 'old_tags' is assigned to but never used
629: local variable 'old_tags' is assigned to but never used
1020: local variable 'lifecycle_
1742: local variable 'old_description' is assigned to but never used
1759: local variable 'old_description' is assigned to but never used
1774: local variable 'old_description' is assigned to but never used
1788: local variable 'old_description' is assigned to but never used
./lib/lp/
3849: local variable 'karma_total' is assigned to but never used
3573: W291 trailing whitespace
3575: W291 trailing whitespace
3577: W291 trailing whitespace
3579: W291 trailing whitespace
3581: W291 trailing whitespace
3598: W291 trailing whitespace
3573: Line has trailing whitespace.
3575: Line has trailing whitespace.
3577: Line has trailing whitespace.
3579: Line has trailing whitespace.
3581: Line has trailing whitespace.
3598: Line has trailing whitespace.
So we have a UI problem, and the desire to restore subscriptions to the previous value when emails for a bug are reenabled.
Is this feature genuinely interesting enough to add the new table, increasing the complexity of how to determine who gets what email?
The DB patch itself seems generally fine
- We will want a who-did-it column to track who muted a team subscription if that is possible.
- You are deleting a load of BugSubscription records. This means the code will need to cope with unmuting a bug with no existing BugSubscription, as well as restoring an existing BugSubscription. Would it not be better to set the affected BugSubscription notification level to something meaningful and avoid the extra code path and tests?