Closed
Bug 238819
Opened 21 years ago
Closed 18 years ago
enter_bug should offer Initial State: ASSIGNED
Categories
(Bugzilla :: Creating/Changing Bugs, enhancement)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.0
People
(Reporter: Biesinger, Assigned: LpSolit)
References
Details
Attachments
(1 file)
(deleted),
patch
|
goobix
:
review+
|
Details | Diff | Splinter Review |
instead of requiring me to change this after I filed the bug, I should be able
to choose it when filing; especially as there is already a list for choosing an
initial state.
Comment 1•21 years ago
|
||
see also bug 35195, which is for reassignments on existing bugs rather than
enter bug.
Assignee | ||
Comment 2•20 years ago
|
||
Christian, do you mean when bugs are assigned to you or in every case? If you
mean when the bug is assigned to you, then this bug is a dupe of bug 116488.
Well... there the reporter asks to change the status to ASSIGNED automatically
and the discussion now goes to have it as an option. Maybe we should dupe 116488
instead.
Reporter | ||
Comment 3•20 years ago
|
||
hmm, well I was mainly thinking of the case where assignee = me, but wouldn't it
be easiest to just add a third entry to that list? (UNCO, NEW, ASSI)
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Assignee | ||
Comment 4•18 years ago
|
||
(In reply to comment #3)
> hmm, well I was mainly thinking of the case where assignee = me, but wouldn't
> it be easiest to just add a third entry to that list? (UNCO, NEW, ASSI)
Probably. We can restrict this later if needed. I can fix this one as soon as bug 341867 lands, due to conflicts.
Assignee: myk → LpSolit
Target Milestone: --- → Bugzilla 2.24
Assignee | ||
Comment 5•18 years ago
|
||
Attachment #228088 -
Flags: review?(bugzilla-mozilla)
Updated•18 years ago
|
Attachment #228088 -
Flags: review?(bugzilla-mozilla) → review+
Updated•18 years ago
|
Status: NEW → ASSIGNED
Flags: approval?
Comment 6•18 years ago
|
||
Comment on attachment 228088 [details] [diff] [review]
patch, v1
It's kind of inconsistent to fix some "bad" values to the right ones, and in other cases to reject the status validation as incorrect.
But again, probably we can end up here only if the user hacked the HTML POST form in the first place.
Assignee | ||
Comment 7•18 years ago
|
||
(In reply to comment #6)
> It's kind of inconsistent to fix some "bad" values to the right ones, and in
> other cases to reject the status validation as incorrect.
It rejects *invalid* statuses (such as FOO), but replaces valid statuses which you cannot use because you haven't enough privs by the correct one. This is not inconsistency. It behaves as if post_bug.cgi was simply ignoring the given status for users with no privs (this is exactly what it does, btw).
Comment 8•18 years ago
|
||
Hmm, seems like there ought to be a better way to do this, but I sure can't think of one. :)
Flags: approval? → approval+
Assignee | ||
Comment 9•18 years ago
|
||
Checking in enter_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/enter_bug.cgi,v <-- enter_bug.cgi
new revision: 1.141; previous revision: 1.140
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v <-- post_bug.cgi
new revision: 1.156; previous revision: 1.155
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•