391059 - Implement the ability to choose which bug status transitions are allowed based on user roles and permissions

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Frédéric Buclin]

Now that we have custom bug statuses, any hardcoded rule must be avoided and simply doesn't make sense. What we need is another admin panel in editworkflow.cgi which controls who can change what.

Comment 1

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 2

[Jan-Frederik Edlich]

Idea: Replace the Hook-Boxes in editworkflow.cgi by Multiple-Selection-Boxes. Via this boxes administrators should be able to select groups from the groups table. Save the results of the boxes. Later, the permission to trigger a specific transition should be checked by the in_group() function in other cgi files.

Comment 3

[acp]

Hello there,

this is a very interesting feature that should be part (imho) of every bug-tracking software.
What could be done here to tackle this would be to replace the checkboxes in editworkflow.cgi by a list of groups (as mentionned in the previous comment) and add a new column in the status_workflow column with the corresponding group having the right to make the transition (that only allows the selection of one group per transition, but that can be easily ammended).

I believe that this can be implemented rather easily; if there are no other major modifications planned, why wait version 4?

Comment 4

[Frédéric Buclin]

For the record, see bug 443394 comment 14 and 10.

Comment 6

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.