Affected users should be carried through from duplicates to master

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.

Above proposal abandoned (see conversation in merge proposal). We're solving this in a non-db-schema-changing way now.

This is marked as fixed, but doesn't appear to be.

Basic test, if ten different people all report the same bug and they are dup'ed together, then the number of affected on the master should be at least ten. Which isn't the case.

Please don't reopen bugs Paul - better to open a new one than conflate potentially different discussions.

@Paul that's https://bugs.launchpad.net/launchpad/+bug/616683

Hi Duncan, thanks for trying to help but this is actually talking about a different but related problem to bug 343110. This bug is already fixed.