Comment 1 for bug 505845

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.