Closed Bug 915682 Opened 11 years ago Closed 11 years ago

Make confirm/unconfirmed configurable for can_confirm members

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 318925

People

(Reporter: hdu, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)
Build ID: 20130805152501

Steps to reproduce:

Some members with can_confirm privileges prefer a default value of UNCONFIRMED. Other can_confirm members prefer a default value of CONFIRMED. 


Actual results:

They unintentionally confirmed issues because they didn't change the default value.


Expected results:

Can_confirm members should have the choice of default-confirmed, default-unconfirmed or an '---' initial state that HAS to be set manually to either confirmed or unconfirmed.
Assignee: general → create-and-change
Severity: normal → enhancement
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Component: Bugzilla-General → Creating/Changing Bugs
Resolution: --- → DUPLICATE
I don't think this is really a duplicate of bug 318925.

Here is why:
THIS enhancement (bug 915682) asks for a single default value for users with can_confirm priviledges.
For me it would not be useful if the system remembers the "last status selected" as stated in bug 318925.

As stated here https://issues.apache.org/ooo/show_bug.cgi?id=122775
Would it be possible to offer a new option say "default status" in the "bug fields" menu. Then one could configure which status is assigned to a newly created bug. CONFIRMED or UNCONFIRMED.
Your proposal doesn't work. Users without canconfirm or editbugs privs cannot use CONFIRMED. And the bug status workflow, which controls valid transitions, may offer additional bug statuses to privileged users.
Hi Frederic,
I can't see, why this won't work. You are right, that users without canconfirm or editbugs privs cannot use CONFIRMED-state. But: As the title says the feature is: "Make confirm/unconfirmed configurable for can_confirm members". So only members of this group can configure the default value.

I also don't get yout point when you say: 
"the bug status workflow, which controls valid transitions, may offer additional bug statuses to privileged users"
In my opinion it is actually possible already to open an new bug in CONFIRMED or UNCONFIRMED state for privileged users as "starting states". So which additional states are you talking about?

The new feature only impacts the pre-selected default value when a new bug is created.
You need to log in before you can comment on or make changes to this bug.