Yes, I am talking about JIRA Workflow Properties.
- Login as a JIRA Administrator
- Navigate to Administration > Global Settings > Workflows
- Create a draft of the workflow if it is active. Navigate to the step which needs to be modified.
- Click on the View step's properties link.
- Enter the permission property into the Property Key field. The property is of the form - jira.permission.[subtasks.]{permission}.{type}[.suffix] where:
- subtasks is optional - If included the permission is applied on the issue's subtasks. If not the permission is applied on the actual issue.
- permission - is a short name specified in Permissions class. Following are the permitted values as on JIRA 4.2
admin, use, sysadmin, project, browse, create, edit, scheduleissue, assign, assignable, attach, resolve, close, comment, delete, work, worklogdeleteall, worklogdeleteown, worklogeditall, worklogeditown, link, sharefilters, groupsubscriptions, move, setsecurity, pickusers, viewversioncontrol, modifyreporter, viewvotersandwatchers, managewatcherlist, bulkchange, commenteditall, commenteditown, commentdeleteall, commentdeleteown, attachdeleteall, attachdeleteown, viewworkflowreadonly - type - type of permission granted/denied. The values can be group, user, assignee, reporter, lead, userCF, projectrole
- suffix - An optional suffix to make the property unique when you have the same type added more than once! jira.permission.edit.group.1, jira.permission.edit.group.2 etc
- Enter the appropriate value in the Property Value field. If the type is group, enter a group. If it a user, enter a user name and so on.
It might be useful to give a few examples here:- jira.permission.comment.group=some-group
- jira.permission.comment.denied=
- jira.permission.edit.group.1=some-group-one
- jira.permission.edit.group.2=some-group-two
- jira.permission.modifyreporter.user=username
- jira.permission.delete.projectrole=10000
- jira.permission.subtasks.delete.projectrole=10000
- Go back and publish the workflow if it was active. If not, associate the workflow with the appropriate schemes.
For example, if you have the Edit permission restricted to jira-administrators in the permission scheme, adding jira.permission.edit.group=jira-users wouldn't grant the permission to jira-users. But instead, if you had both those groups in the Edit permission, only jira-users will be allowed to Edit as defined in the workflow permission.
Now take this opportunity and remove some of the code in your issue operations plugin that displays operations based on status ;)