|
Having roles would be very useful for us. We have needed to code an ugly feature ourselves. We made a workflow condition which check for a group whose name is made up with the project key and a condition parameter. So we assign groups:
ANA_PP (analyst in project PP) But is cumbersome. We have lots and lots of these ugly groups. A new "roles" feature will be perfect for us and for other companies having lots of projects. This seems more a Workflow feature than a Security/Permissions issue. We need to be able to set a project and/or component Project Lead and QA Lead. Then, for example, we could create a workflow that says when a developer marks an issue resolved it gets automatically assigned to the QA Lead.
There may be similiar workflows needed for Development Lead or Documentation Lead. Kevin,
Roles could be used in many places, including automatic actions on workflow transitions. Jira supports "Reporter" as a role that it maintains. Also "Assignee".
It would be nice to add "Project Lead" to that list as well. Role-names should be available in every name picker, and in every situation in which I can select a name/person, including conditions and post functions. ADDITIONALLY - It would be extremely nice if Jira maintained a name field for every status (or workflow step) and automatically put into that field the name of the person who caused the issue transition to the next step (which might have been a member of a group and not necessarily the asignee at the time of the transition). That would provide a complete and very nice audit trail. Those name fields should be referenceable as roles, e.g. the resolver, the closer, the verifier, etc. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Project roles
The ability to define QA and Development leads for each component has been repeatedly requested.