Affected users should be carried through from duplicates to master
Bug #505845 reported by
Graham Binns
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Medium
|
Karl Fogel |
Bug Description
What happens:
At the moment, when a bug has duplicates its affected users (from Bug.users_affected) list only contains those users who have marked that bug as affected. Affected users from duplicates are ignored.
What should happen:
The affected users from duplicates should be accessible from the duplicated bug, either as a separate attribute (users_
This is particularly important for the bug heat work since the number of users affected by a bug will alter that bug's hotness. Including users affected by duplicates will paint a more accurate picture.
Related branches
lp:~kfogel/launchpad/505845-affects-person-from-dups
Merged
into
lp:launchpad
- Graham Binns (community): Approve (code)
- Karl Fogel (community): Needs Resubmitting
-
Diff: 308 lines (+219/-5)5 files modifiedlib/lp/bugs/configure.zcml (+3/-0)
lib/lp/bugs/doc/bug.txt (+145/-1)
lib/lp/bugs/interfaces/bug.py (+22/-2)
lib/lp/bugs/model/bug.py (+46/-2)
lib/lp/bugs/stories/webservice/xx-bug.txt (+3/-0)
summary: |
- Affected users should be carried through to duplicates + Affected users should be carried through from duplicates to master |
Changed in malone: | |
assignee: | nobody → Karl Fogel (kfogel) |
status: | Triaged → In Progress |
milestone: | none → 10.01 |
Changed in malone: | |
status: | In Progress → Fix Committed |
Changed in malone: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Proposed solution (from adeuring, gmb, kfogel):
Add a new column:
ALTER table bugaffectsperson ADD COLUMN master_affects integer;
By default, the new column has the same value as 'bug'. But when a bug D is marked as a dup of bug M, D's 'master_affects' is set to M (unless there was already a record indicating M does not affect P).
Then we do most queries on the 'master_affects' column (instead of on 'bug' as currently). For example, when a person P visits the page for bug M, we figure out whether to show it as affecting them based on whether there are any rows with M in 'master_affects'. And when we're calculating total affects-person counts for bug heat, we query on the master_affects column. Thus, if D is later unduplicated from M, the affects-person count on M will automatically be decremented properly.
Here are some scenarios and how they would be handled:
* P changes mind after duplication and says "M does not affect me". ANSWER: find all bugs where master_affects is 'M' but 'bug' is *not* M, and set master_affects back to bug's value; simultaneously, add a new row saying that M does not affect P. Give a UI warning to P about how the inconsistency (maybe they're wrong about M not affecting them, or maybe D and M aren't dups after all, whatever).
* P changes mind (after duplication) and says "D does not affect me". ANSWER: set affects to False for D<->P.
* P is affected by D and by M *before* D is marked as dup of M; then P says "not affected by M", while staying affected by D; then later some other person Q marks D as dup of M. ANSWER: Do it, but warn Q that there is an inconsistency (in that P has explicitly claimed to be affected by D and unaffected by M).
* P is claims affected by D; then D is marked as a dup of M; then P claims unaffected by M; then someone (P or someone else) undups D and M; then someone re-dups them. ANSWER: This is okay. When P first claims unaffected by M, we will set D<->P's master_affects back to D (from M), *and* add a row "bug: M; person: P; affected: False; master_affects: M". When the unduplication happens, these rows will remain unchanged; and when the re-duplication happens, the M<->P row will prevent the D<->P relationship from being re-established.
* If we have several duplicates of one master bug M, then we increment M's affected count by 1 for each person affected by it, regardless of the number of dups by which that person is affected. In other words, if P is affected by D1, D2, D3, and all those are dups of M (along with D4, D5, and D6), then M's affects-person count goes up by 1 for P, not by 3. And of course, when P visits M, M is shown as affecting them.
Final note: don't worry about the "Bug X marked as dup of Y, then
marked as dup of Z" scenario, since the current UI prevents this from
happening at all.