Closed Bug 112319 Opened 23 years ago Closed 10 years ago

admin-defined roles. replaces hardcoded QA.

Categories

(Bugzilla :: Administration, task, P3)

Tracking

()

RESOLVED DUPLICATE of bug 287332

People

(Reporter: pbaker, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [blocker will fix])

I was contemplating putting a feature request for a "release coordinator" email
field. The reasoning behind this, is that at my company through the life of a
bug, there are 3 people that generally work on a bug.

1. When the bug is assigned to the owner, the owner hopefully fixes the bug and
then the bug is marked as RESOLVED.
2. After that the QA contact double checks that the fix actually resolves the
issue. This person either marks the bug REOPENED and it is sent back to the
assignee, or VERIFIED is marked.
3. When a bug is marked VERIFIED, then the third person, the Release Coordinator
(RC) is responsible for deploying the fix into production. When this happens,
the RC then marks the bug as CLOSED.

The absense of a field to enter in who the RC is makes our process less than
elegant.

After talking with justdave on IRC, we came to the conclusion that general roles
feature should be created. The existing QA behaviour would then use this new
roles feature. Here are some of the points we came up with.

<justdave> I'm starting to think we need admin-definable "roles". an adjustable
number of roles that the admin can define what they're called. eliminate QA from
the bugs table. owner can stay there, since bugs more or less HAVE to have an
owner. 
<justdave> have a bug_roles table... bug_id, role_id, user_id. 
<justdave> roles table... role_id, role_name, role_desc 
<justdave> component_roles table... component_id, role_id, default_user_id 

<pbaker> you also need to be able to specify certain privileges to the roles, my
"qa" role can verify, but not resolve or close, etc etc.
Component: User Accounts → Administration
Would be very nice, but perhaps a bit blue sky at the moment so moving to
Future.
Priority: -- → P3
Target Milestone: --- → Future
Depends on: bz-customfields
Whiteboard: [blocker will fix]
Target Milestone: Future → Bugzilla 2.18
OS: Linux → All
Hardware: PC → All
Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Depends on: 287332
No longer depends on: bz-customfields
*** Bug 287333 has been marked as a duplicate of this bug. ***
Assignee: myk → administration
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
287332 (have custom "User" fields) would be the way to do this.

Gerv
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.