Closed Bug 238819 Opened 21 years ago Closed 18 years ago

enter_bug should offer Initial State: ASSIGNED

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

2.17.6
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.0

People

(Reporter: Biesinger, Assigned: LpSolit)

References

Details

Attachments

(1 file)

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.
see also bug 35195, which is for reassignments on existing bugs rather than enter bug.
Severity: normal → enhancement
Depends on: bz-custstat
OS: Linux → All
Hardware: PC → All
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.
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)
Blocks: 315860
QA Contact: mattyt-bugzilla → default-qa
(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
Depends on: 341867
No longer depends on: bz-custstat
Target Milestone: --- → Bugzilla 2.24
Attached patch patch, v1 (deleted) — Splinter Review
Attachment #228088 - Flags: review?(bugzilla-mozilla)
Attachment #228088 - Flags: review?(bugzilla-mozilla) → review+
Status: NEW → ASSIGNED
Flags: approval?
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.
(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).
Hmm, seems like there ought to be a better way to do this, but I sure can't think of one. :)
Flags: approval? → approval+
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
Keywords: relnote
Added to the relnotes currently attached to bug 349423.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: