110796 - reopening a bug sents status "New"

Status: RESOLVED WORKSFORME

(Bugzilla :: Email Notifications, enhancement, P3)

Description

[Vaskin Kissoyan]

its just not new

Comment 1

[Matthew Tuck [:CodeMachine]]

Please elaborate on this as we can't do much with the amount of detail this
report gives.

Are you saying you get "New" on the subject line of notifications you receive,
or the status becomes "New" rather than "Reopened" upon reopening?  I can't
reproduce either.

Are you making any other changes at the same time as reopening?

Does it always happen?

Comment 2

[Dave Miller [:justdave]]

Changing default owner of Email Notifications component to JayPee, a.k.a.
J. Paul Reed ([e-mail]).  Jake will be offline for a few months.

Comment 3

[Matthew Tuck [:CodeMachine]]

Moving to Future until we get some more detail on this report from
[e-mail].

Comment 4

[Brad Clarke]

2.16rc1

just found that a mass change of Assigned To moved all the REOPENED items to
NEW...could this be related?

Comment 5

[Matthew Tuck [:CodeMachine]]

Reassignment of bugs in the REOPENED or ASSIGNED statuses will move them to NEW
- that is by design.

Comment 6

[Vaskin Kissoyan]

I guess the actual issue I originally complained about was that:

if its "NEW" it should say "New:" (as expected)
if its "REOPENED" it should say something besides what it says now "New:"
    * It could say "Reopened:"
    * It could say "New (reopened):"

or it could indicate that the bug is in a status where it will whine at you if
you don't do anything (which is kinda what it indicates, but not exactly). This
indicator would come up if status = NEW or REOPENED

I'm not sure what the exact solution is, but there-in lies the confusion of what
"New:" means for me.

Comment 7

[Matthew Tuck [:CodeMachine]]

When the notifications get templatised, this will probably be a lot more
customisable.

Comment 8

[David McCormack]

I am experiencing this error 2.17.6, and the error can be reproduced by:
  Create New Bug
  Change Status to Assigned
  Re-Assign the Bug to Someone Else

* Bam, the status has been reset to New

Comment 9

[Dave Miller [:justdave]]

As noted in comment 5, that's by design (i.e. it's new to that developer).

Comment 10

[timeless]

We should probably rename 'new' to 'confirmed' and then add the ability to mark
a bug as unconfirmed.

Comment 11

[Vlad Dascalu]

> We should probably rename 'new' to 'confirmed' and then add the ability to mark
> a bug as unconfirmed.

It wouldn't make much sense to give people to create bugs from the start with
the "confirmed" state. The word "confirmed" implicates that someone else read
your bug and confirmed it, so it implies at least 2 persons.

Comment 12

[Frédéric Buclin]

(In reply to comment #11)
> > We should probably rename 'new' to 'confirmed' and then add the ability to mark
> > a bug as unconfirmed.
> 
> It wouldn't make much sense to give people to create bugs from the start with
> the "confirmed" state. The word "confirmed" implicates that someone else read
> your bug and confirmed it, so it implies at least 2 persons.

See bug 266297 which requests the ability to change the status to UNCONFIRMED.

Comment 13

[Dave Miller [:justdave]]

The reporters clarification in comment 6 clearly shows that he was complaining
about the subject line of the email, not the bug status, and I've never seen the
email system send something with New: on the subject line when a bug got
reopened.  The rest of the ideas other helpful people tried to morph this into
are all covered on other bugs.

Comment 14

[Dave Miller [:justdave]]

clearing target for resolved other than fixed, so they'll show up as untriaged
if they ever get reopened.