Bug 234261

Summary:	NEEDINFO gets automagically to ASSIGNED
Product:	[Community] Bugzilla	Reporter:	Matěj Cepl <mcepl>
Component:	Bugzilla General	Assignee:	PnT DevOps Devs <hss-ied-bugs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.18
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	2.18	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-09-18 02:51:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matěj Cepl 2007-03-27 22:42:20 UTC

Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. a reporter files a bug, which is marked as NEW
2. the owner of the bug requires additional information for determining whether
it is a bug, whether it shouldn't be filed upstream etc.
3. the reporter replies to this request
  
Actual results:
bugs status is changed to ASSIGNED

Expected results:
according to
https://bugzilla.redhat.com/bugzilla/page.cgi?id=fields.html#needinfo it should
go back to the previous status -- NEW in this example

Additional info:
I am a bugmaster for the desktop team. The first phase of my handling with the
bug is to determine whether the bug is reproducible, whether it shouldn't be
filed upstream, etc. For this I have to obtain necessary information (e.g.,
logs), so in order to make this determination I have to ask a reporter for
additional information, so I switch NEEDINFO on the bug. When the reporter
answers, I still need to decide what to do, and which engineer should handle the
bug, or I have to make additional triaging to find out what to do with the bug.
So IMHO the bug should still be NEW. However, bugzilla marks the bug as ASSIGNED
to the owner of the bug.

Some workarounds are possible (like make the owner of the component some virtual
email address, so that the bug is ASSIGNed to it, and not to the real person, or
make me assignee of such bugs), but still BZ doesn't work as described in the
docuement referenced above.

Comment 1 Matěj Cepl 2007-03-27 22:49:46 UTC

Probably relates to bug 179897.

Comment 2 Noura El hawary 2007-09-18 02:50:52 UTC

Hi Matej ,,

We will apply a FIX for that in the next day or so .. So when a bug is in
NEEDINFO status and the requestee provides the info needed the status will
change back to the previous state before NEEDINFO and not to ASSIGNED.

Comment 3 Matěj Cepl 2007-09-18 10:50:41 UTC

That will be so cool!!! THANKS!!!

Comment 4 David Lawrence 2007-09-18 18:01:36 UTC

This fix should be live now.