Display "Duplicate" as if it's a status

Reported by Corey Burger on 2005-11-01
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

Marking a bug as duplicate should change the status to Duplicate, so that the status shows up a listing of bugs.
This also affects the Latests bugs portlet.

The implementation plan looks like this:

  * Add IBugTask.display_status, which returns the appropriate
    status title.
  * Change all the template code, that uses task/status/title,
    to use task/display_status.
  * We don't want people editing duplicate bugtasks, so changing
    EditBugTask.checkAuthenticated() to return False if the bug
    is a duplicate is probably a good idea. Maybe even redirect
    +editstatus to +viewstatus, with an appropriate notification
    message.

I think that's all that needs to be done. Changing all the call sites is probably the most tricky one, since there are quite a few, the bug page, all the buglistings, portlets, and so on. A test should be added for every call site that is changed.

Brad Bollenbach (bradb) wrote :

We can extrapolate duplicateness quickly and easily from the Bug.duplicateof property.

Wouldn't adding an extra status for this be needless, error-prone duplication of that information, as long as there are other ways to access lists of bugs that are marked duplicates?

Changed in malone:
status: New → NeedInfo
Corey Burger (corey.burger) wrote :

The status refers to where the bug is at in its lifecycle. Duplicate is an end status in that lifecycle and thus should be reflected as that. Having a bug that is both fixed and duplicated is wrong to me (even if their are other bug trackers that do that)

On Mon, Nov 28, 2005 at 07:50:53PM -0000, Brad Bollenbach wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/3796
>
> Comment:
> We can extrapolate duplicateness quickly and easily from the
> Bug.duplicateof property.
>
> Wouldn't adding an extra status for this be needless, error-prone
> duplication of that information, as long as there are other ways to
> access lists of bugs that are marked duplicates?

We wouldn't need to add it as another status, like the other, New,
Accepted, etc., we could have it as a 'virtual' status instead. If the
bug is a duplicate, we'd display the status as Duplicate, while the
status stored in the database wouldn't be changed, it would still be New
or something like that. If the bug would be unmarked as a duplicate, the
original status would automagically reappear.

I like this idea. We get the necessary UI of having only one status but don't lose the important information about where it is at if it not actually a duplicate (something I realize now)

Christian Reis (kiko) wrote :

Brad, if Bjorn's suggestion doesn't sound too complicated (I'm assuming we would only /present/ "DUPLICATE" for all bugs bugtasks' status and not make any changes to the database side of things) I'm okay with it.

Le 29-Nov-05 à 2:36 AM, Björn Tillenius a écrit :

> Public bug report changed:
> https://launchpad.net/malone/bugs/3796
>
> Comment:
> On Mon, Nov 28, 2005 at 07:50:53PM -0000, Brad Bollenbach wrote:
>> Public bug report changed:
>> https://launchpad.net/malone/bugs/3796
>>
>> Comment:
>> We can extrapolate duplicateness quickly and easily from the
>> Bug.duplicateof property.
>>
>> Wouldn't adding an extra status for this be needless, error-prone
>> duplication of that information, as long as there are other ways to
>> access lists of bugs that are marked duplicates?
>
> We wouldn't need to add it as another status, like the other, New,
> Accepted, etc., we could have it as a 'virtual' status instead. If the
> bug is a duplicate, we'd display the status as Duplicate, while the
> status stored in the database wouldn't be changed, it would still
> be New
> or something like that. If the bug would be unmarked as a
> duplicate, the
> original status would automagically reappear.

This seems doable. It *may* even be that we can avoid the extremely
hairy mess of "task merging" by not doing task merging at all, simply
auto-displaying "Duplicate" status for all tasks that are marked as
dups. More thinking required.

  affects /products/malone
  status accepted
  assignee bradb

Cheers,

--
Brad Bollenbach

Changed in malone:
assignee: nobody → bradb
status: NeedInfo → Accepted
description: updated
description: updated

I've updated the description with the implementation plan. If anything is unclear, just ask me.

Don't forget that adding attributes to IBugTask is a bit tricky, you need to edit bugtask.zcml as well, adding the attribute to the <content class="...BugTask"> directive, otherwise you won't be allowed to access it.

Changed in malone:
assignee: bradb → matsubara
description: updated
Matthew Paul Thomas (mpt) wrote :

<https://wiki.launchpad.canonical.com/MaloneSearch> requires that we (eventually) be able to search for bug reports that are duplicates, aren't duplicates, or both.

<https://wiki.launchpad.canonical.com/DuplicateBugHandling> (which I haven't finished yet) requires that if a duplicate marking is removed, the bug's tasks resume their previous statuses.

It looks like the implementation plan here will allow both those things, but I'm not sure. If it won't, please discuss it so the plan and/or the specs can be adjusted.

On Thu, Feb 09, 2006 at 02:38:05AM -0000, Matthew Paul Thomas wrote:
> <https://wiki.launchpad.canonical.com/MaloneSearch> requires that we
> (eventually) be able to search for bug reports that are duplicates,
> aren't duplicates, or both.
>
> <https://wiki.launchpad.canonical.com/DuplicateBugHandling> (which I
> haven't finished yet) requires that if a duplicate marking is removed,
> the bug's tasks resume their previous statuses.
>
> It looks like the implementation plan here will allow both those things,
> but I'm not sure. If it won't, please discuss it so the plan and/or the
> specs can be adjusted.

Yes, the implementation will allow for searching for duplicates, and
for returning the bug to the state it was when it got marked as a
duplicate.

Anyway, I see this as a quick and easy fix which will improve things in
the short term. If you would come up with some other solution in
DuplicateBugHandling, this fix is easy to revert.

The magical fabrication of status is something that Brad can work on once we've got the API for changing status sorted out.

Changed in malone:
assignee: matsubara → bradb
Christian Reis (kiko) wrote :

Note however that most callsites now ignore dupes in their queries for bugtasks.

Brad Bollenbach (bradb) on 2006-06-22
Changed in malone:
assignee: bradb → nobody
Christian Reis (kiko) wrote :

And we now hide the status of the duplicate bug, which further reduces the impetus to do wrong things to it.

Changed in malone:
importance: Medium → Low
towsonu2003 (towsonu2003) wrote :

>we now hide the status of the duplicate bug

I think you can now close this one.

Matthew Paul Thomas (mpt) wrote :

The remaining use case for this is an advanced search with "Hide duplicate bugs" unchecked.

Matthew Paul Thomas (mpt) wrote :

... And in the list of bugs targeted at a milestone -- see bug 86498.

James Henstridge (jamesh) wrote :

For the bug listing, how about showing text like "Duplicate of #NNNN" instead of the status and importance? This would be consistent with hiding status/importance on the bug page itself, and if the text spanned those two columns, it shouldn't affect the overall width of the table.

era (era) wrote :

Whatever the implementation on the back end, when you do get to see a bug which is a duplicate of another, it should be clearly visible that it is a duplicate.

It seems to me that the topic of this bug is a rather complex problem, if you look at the interactions between this bug, bug #61429. bug #50549, etc. I don't think it should be closed simply by hiding duplicates and/or asserting that people who need to see and manipulate duplicates can somehow find them by explicitly searching for them.

Stephen Warren (srwarren) wrote :

To me, this is the #1 wart in the launchpad bug system (yup, everything else works pretty well).

Take a look at bug 377476 (or even this one I guess). Now, go to every bug that's marked a duplicate. In each marked-as-dup bug, the "Status" column in the table at the top of the bug is something that a) Isn't correlated with the real status of the bug (i.e. whatever the "master" dup's status is and b) Doesn't indicate that it's a dup, so it's not obvious to the user that it's not correct. The only indication of dup is the small text in the top-right saying so (instead, this text should be a huge cue in the UI so it's obvious, not something tiny and hidden), plus the warning above the add-new-comment box, which could well be hidden under N pages of comments before the bug was marked as a dup.

A related feature I'd like to request is auditing of dup marking. There is nothing in the comment log indicating who marked the bug a dup, nor when they did it, nor why. Other status changes (e.g. New -> Invalid) at least give user/date/old-state/new-state. Marking a bug as a dup should make a similar comment entry. (I feel this would be better implemented as making "Duplicate" a status value, rather than adding new special-case code to make this comment entry when marking as a dup, but I'm not familiar with Launchpad code).

Matthew Paul Thomas (mpt) wrote :

Making "Duplicate" a real status wouldn't work well, because real statuses are context-specific, and a single bug report can have multiple contexts.

I've reported showing marking/unmarking a duplicate as bug 446234.

Kangarooo Jānis (kangarooo) wrote :

When making a dublicate bug status should be showing as the same as main bug and also in main bug should be added comment that a dublicate bug is added so it raises awarnes couse maybe solution can been seen in dublicate bug but if noone know dublicate is added then noone sees that. Also maybe dublicate should be integrated in main bug.

Ive reported that king of integration as bug 533804

Matthew Paul Thomas (mpt) wrote :

Bug 3796, bug 299283, and bug 492011 are mutually exclusive solutions for bug 295224. I'm marking them all as duplicates.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints