> 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
Le 29-Nov-05 à 2:36 AM, Björn Tillenius a écrit :
> Public bug report changed: /launchpad. net/malone/ bugs/3796 /launchpad. net/malone/ bugs/3796
> https:/
>
> Comment:
> On Mon, Nov 28, 2005 at 07:50:53PM -0000, Brad Bollenbach wrote:
>> Public bug report changed:
>> https:/
>>
>> 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