I was happy initially to find this post, but now sad that it was closed as Resolved with actually providing no meaningful resolution to so many of customers demands. In general, one more vote up that you should re-consider this and add to your product roadmaps some flexible and actually effective way to manage user/group relationships. Such a trivial thing should most definitely be part of your core offering, it's not professional to state partial solutions by third party vendors. This is core. If you really are after ITSM markets to challenge leaders like ServiceNow (where this feature has been existing in the core functionalities for years now), you need to make sure the capabilities match.

Hello to all JIRA customers watching this issue.

Firstly on behalf of the JIRA team please accept our apologies for allowing this issue to be open for so long without any strong direction.

We have taken a long hard look at this issue and we have decided that adding further permissions to a workflow status is not where we will be taking JIRA. The main reason for this is that we are super focused on making JIRA more simple to use and administer. So whilst adding in this feature and others like it (eg. JRA-5865) would make JIRA more powerful - it would also add a high degree of complexity.

Some of you may already know this but you can already enforce a particular permission check at any stage in the workflow via Workflow Properties as described in this blog post by Jtricks. This does take a little JIRA knowledge but it certainly can be done. Additionally for some use cases contained in this issue another approach is to use the popular JIRA Suite Utilities. With this plugin you can add further workflow conditions and validators to JIRA transitions.

This decision was not made lightly and we hope you appreciate our open approach to these requests. There are many exciting new features coming up in JIRA that we believe will have an even greater benefit to JIRA customers.

If you have any questions or concerns feel free to contact me directly.

Cheers,
Roy Krishna
JIRA Product Management
roy at atlassian dot com

Yes, this is very necessary for our workflow, and as a result we are settling for a broken inefficient use of JIRA. We are an Unlimited JIRA License organization, but our needs arent much greater than this.

Example: In one case, we need the Manager to be the only one allowed to assign tasks to users, not allowing users to reassign their neighbor if they dont want to do something. However, in cases where a project requires the user to create a subtask, now they dont have permission to assign the subtask to anyone, so it has to go back to the manager to read the note on who the subtask was supposed to go to, and he has to do it every time. Furthermore, there are states in the workflow where there are multiple options within a project group that could be assigned directly from a user where the Manager doesnt care. But this is restricted now too under the current JIRA limitation.

I hope this can be resolved soon. I also want to say that I think JIRA is absolutely a great tool.

Concern: This last thought may be at odds with Atlassian, and may render any work they do on this issue useless to us. But I would like to see this functionality updated into both JIRA branches, 4.0.x and 4.1.x service releases because our organization flatly refuses and rejects 4.1 due to the slow, inefficient, and hard to read and navigate layout forced upon us in 4.1. Unless they revert to the 4.0 display format, or add an administrative option to display JIRA as 4.0, or fix the serious failures in User Interface introduced in 4.1, ...and they choose to only fix this JRA-6381 in 4.1, then we will never be able to use it.

I hope they can make some decisions on these issues soon to help us, and all other customers who need these features to use JIRA they way they need. My thought is that without the updates contained in this comment, we will likely discontinue paying the yearly maintenance.

Elad:
This issue has 5 years, so i think better is to use plugin than wait for jira with this plugin as standard function.
For compatibility with different versions of jira, check plugin web page.
Tyler:
I use this plugin 2 years, and works correctly on jira 3.13.

Thanks!

Elad,

I could not get the "User Picker from Project Role" plugin working. My workaround was to use another select list and then some javascript that copies the username from the custom select list to the user picker field. I hated having to do it, but oh well.

We are now evaluating JIRA for using it for a large scale project in Kodak. The inability to choose assignee from a limited list when transitioning the issue workflow step is a major issue for us.
Is there an expected due date for a fix of this?
Is the plug-in mentioned above (User Picker From Project Role) relevant for the latest JIRA version?

We have been customizing our workflow with great success. It's fantastic that we can write our own simple workflow customizations and plug them in.

So, on to "assign user", oops, that's an "issue operation". Are issue operations a remnant of the past? In my estimation, if the issue operations were workflows, we could customize them with the readily available means...or am I missing something? Perhaps it is the issue of bulk operations, but I see little difference conceptually in "assign issue" (issue op) vs. "resolve issue" or "start progress" (workflow transitions).

We realy need this function to prefent customers from commenting on closed issues. Is there some workarround for this?

I think two things are important to write to this workaround before jira-administrators will start using this plugin and changing their workflows:

1. plugin is for version 3.12 of jira.

2. this plugin is not officialy supported - noone will guarantee this plugin will work properly with other versions of jira

3. actually one bug is reported in this plugin - it's a minor bug, only huge WARN logs are generating.