Bug listings include reports multiple times for multiple targets

Bug #1357 reported by Matthew Paul Thomas on 2005-07-10
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

If a bug affects more than one project or package, it can appear multiple times in search results. This should not happen: a bug should appear only once.

Screenshot: <http://librarian.launchpad.net/5575576/duplicate.png>

See also bug 43078 (the same problem in a distribution's "Latest bugs" list), bug 163241, bug 311681 (returning a report once for each patch it contains), and bug 516050 (returning a report once for a series and once for a milestone).

Brad Bollenbach (bradb) on 2005-11-02
Changed in malone:
assignee: nobody → bradb
status: New → Accepted
Brad Bollenbach (bradb) on 2006-08-18
Changed in malone:
assignee: bradb → nobody
description: updated

This bug is marked as a duplicate of bug 43078.

Although these bugs have the same underlying cause, bug 43078 is more serious, because it's about the "recently filed bugs" box shown on a distribution series' front page. There are only five bugs shown in this prominent location, and to have one of those five shown twice looks very silly.

Steve Alexander (stevea) wrote :

I'd actually be inclined to un-dupe bug 43078, and fix that with a quick check in the python code to not display duplicates. That's a much easier problem to fix than fixing it for all searches displaying arbitrary batched results.

description: updated

I wouldn't advise 'fixing' this in +assignedbugs, at least. That would be a big usability regression, as assignments are per-task, and I like to be able know what I'm actually assigned to.

description: updated

One way to fix this would be to still display all the projects/packages for the bug, but to group them together into a single search result.

Martin Albisetti (beuno) wrote :
Matthew Paul Thomas (mpt) wrote :

Where the projects/packages give the bug different Importance values, it will be necessary to calculate an aggregate or overall importance value, to decide what icon to show for the single search result. This is also needed in bug 225219.

Matthew Paul Thomas (mpt) wrote :

Colin Watson in <https://lists.ubuntu.com/archives/ubuntu-devel/2008-October/026729.html>: "https://bugs.launchpad.net/ubuntu/+bugs?field.has_patch=on is hopeless because it consists of 25 pages and has lots of duplicated bug numbers; I'm never going to skim through that looking for things I'm an expert on."

I agreed the list should based on bug number. Repeating the same bug few time is annoying.

era (era) wrote :

How about adding special cases to the code, to split only when necessary? There should still be an option to suppress the joining, I suppose, but for a lot of users, the joined list is all they are ever going to want, and a significant usability improvement over the current code.

era (era) wrote :

> See also bug 43078 and bug 163421.

The link to bug 163421 in the problem description seems rather mysterious. Is this a typo for a different bug number?

description: updated
description: updated
era (era) wrote :

> Is this a typo for a different bug number?

(Found the right bug number and corrected it, some time ago already. Adding a follow-up just to make this a bit less mysterious to the newcomer.)

era (era) wrote :

Furthermore, if something is changed in one of the tasks (i.e. gnomovision (Baltix) changes their task from New to Confirmed) the "last changed" date for all tasks is updated. This makes sorting by "most recently changed" rather futile for bugs with multiple targets. Adding insult to injury, duplicate bugs are obscured from view, even when the search criteria would specifically target duplicates (i.e. +subscribedbugs will not show where you are actually subscribed; bug #61429)

Toni Ruottu (toni-ruottu) wrote :

Let me suggest all Launchpad developers to throw one comment at bug #1. This way we will get this bug out of picture sooner rather than later. I made that mistake once myself, and now I'm doomed to have my personal bug listing filled with projects affected by that bug.


description: updated
Martin Albisetti (beuno) wrote :

So, more thoughts on this.
One way to convey better what is going on, would be to visually group the bugtarget with the bug number. That way when you scan down the list, you will see the duplicate number, but related to a different project/task.

So, something like:

| #1234 - Firefox | Something wrong about something | Low | Confirmed |
| #4234 - Thunderbird | Emails something something | Low | Confirmed |
| #1234 - xul-runner | Something wrong about something | Low | Confirmed |

The visuals could vary, use a border and keep them as 2 cells, but that's the main idea.

era (era) wrote :

Martin: I don't understand your proposal. My counter-proposal would be to group duplicates together for easier skipping, as a very minimal workaround, perhaps with a plan to merge them in a later iteration (maybe show the package field as "multiple packages" or a dropdown or something?)

Changed in launchpad:
importance: Medium → Low
William Grant (wgrant) on 2015-09-11
tags: added: bug-search
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments