Bug listings include reports multiple times for multiple targets

Bug #1357 reported by Matthew Paul Thomas
200
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

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)
Changed in malone:
assignee: nobody → bradb
status: New → Accepted
Brad Bollenbach (bradb)
Changed in malone:
assignee: bradb → nobody
description: updated
Revision history for this message
Steve Alexander (stevea) wrote : Re: Search results should return each bug only once

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.

Revision history for this message
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
Revision history for this message
William Grant (wgrant) wrote : Re: Personal bug listings should return each bug only once

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
Revision history for this message
Matthew Paul Thomas (mpt) wrote : Re: Bug listings should return each bug only once

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.

Revision history for this message
Martin Albisetti (beuno) wrote :
Revision history for this message
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.

Revision history for this message
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."

Revision history for this message
Wawrzyniec Niewodniczański (wawrzek) wrote :

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

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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.)

Revision history for this message
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)

Revision history for this message
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.

https://bugs.launchpad.net/~toni-ruottu?orderby=-users_affected_count

description: updated
Revision history for this message
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.

Revision history for this message
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)
tags: added: bug-search
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments