Display "Duplicate" as if it's a status

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?

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)

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

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.

<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.

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

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

>we now hide the status of the duplicate bug

I think you can now close this one.

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

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

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.

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.

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).

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.

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

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