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 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.

PARTIAL WORKAROUND: Do you need users without edit rights to have some ability to reassign issues? Try the User Picker From Project Role plugin to be able to reassign based on a custom field for groups.

Thanks!!! Got it to work....

Where is the list of "properties" that you can define in JIRA? These
are great.

Susan

Susan,

The jira.permission.* and jira.issue.editable properties only work on workflow steps and not on transitions.

Hope this helps.

Gilles,

I tried defining the assignable group in the properties of the
Transition and it didn't do any sort of restriction. The full list of
users continues to come up in the "assign" field. I tried every step of
the workflow. Am I doing something wrong?

Thanks........Susan

The following page contains some piece of info that might actually help some of you guys out.

Basically you can add extra restrictions on transitions and steps of your workflows by adding extra properties to them.

A couple of examples:

• jira.permission.assignable.group=QA
  • means that only members of the QA group will be assignable in this particular state.
• jira.permission.comment=denied
  • means that commenting is denied in this particular state.

We are just implementing JIRA for the first time, and was very disappointed not to be able to restrict the assignability to users on the Workflow. This is a much needed feature.

We brought JIRA into our developement group for issue/bug tracking, but it escaped: the CIO wants it to be our ITS-wide issue tracking system. Unfortunately, without workflow based permissions I don't think I'll be able to met our needs.

Lieber Mail-Sender

Bis zum 05.01.2008 weile ich ausser Hause und werde keine Email lesen.
Ihre Email wird nicht automatisch weitergeleitet.

Mit freundlichem Gruss und besten Wuenschen fuers Neue Jahr

Erwin Achermann

We are interested in this as well. The permissions would open a whole new market segment for JIRA as a solid workflow solution. However, without the permissioning it doesn't cut it for workflows.

Is there any news on this one?

Really needed. In a big company with many users it would be really a help to limit the users to certain group on each step.

I can't believe you can't do this. I have just setup a complex workflow only to find that there is no control over the permissions.

I also cant believe that this feature has been sitting in a queue for 3 years.

Yes! This would be perfect. We want to be able to change permissions on issues based on issue type, and this would work for that. For instance, Change Orders are very restrictive and can only be modified by a small subset of the development team.

We would very much like to restrict the ability to comment based on workflow state.

Jeff.

I'd be very interested in setting up a situation where you cannot comment on a closed issue!

Sebastian you rock
thanks a lot , i'll use it

Hi Tal,
you could add a custom user picker to your assign screen and use Phil Herbst's Assign From Custom Field Plugin (http://confluence.atlassian.com/display/JIRAEXT/Assign+From+Customfield+Plugin) in your workflow. Then the reporter does not need the assign pemission.

my new corp id is monika.joshi@corp.aol.com , Pls send all your mails to my new corp id

Guys , any news regarding this one?
i am facing a customer who wishes the reporter to be able to do assign only once
so i have a customized workflow with a "assign" screen
but if the reporter does not have the assign permission , he don't see the Assignee field
but if he has the assign permission , he will always have the operation Assign , arrrrrrr

any workaround ?

Ping ping ping.

Allowing an issue to get assigned to a member of different group than one which should be responsible for handling the issue in a given state can result in losing the issue which's really bad.

E.g. if I transition the issue to "To Be Documented" but assign it to Peter which's a QA guy (say, by mistake), the issue will likely get lost because Peter knows he never gets issues in "To Be Documented" and may have filters saved which prevent him from seeing those.

Email notifications on "Issue Assigned" event partly help, yet they don't give a warranty unless Peter is 0% lazy and has less than 200% workload.

Hi folks,

We're using 3.8, the issue still persists. Did I get it right that there are some plugins that solve the problem?

Abwesenheitsnotiz:

Vielen Dank für Ihre Mitteilung.

Momentan bin ich abwesend.

Ich bin ab 23.07.2007 wieder für Sie da. Ihre Mail wird nicht automatisch weitergeleitet.

Falls Ihr Anliegen vorher Aufmerksamkeit erfordert, wenden Sie sich bitte an +41 41 727 2131 oder support@systransis.ch

Notice of absence:

Thank very much you for your inquiry.

At the moment I am away from my desk and my e-mail.

I will be back on 23 Julz 2007. Your e-mail will NOT be forwarded automatically.

Should you need to contact someone before this date, please call +41 41 727 2131 or send a message to support@systransis.ch

Darren, JIRA Suite utilities/extension pack provides this functionality among others, you may want to have a look. We have configured more complex workflows with permissions for http://mule.mulesource.org/jira

^^ bump ^^ Any news guys?

nudge nudge.

A lot of votes...
I know you guys are very busy and there are other pressing issues but any status update on this

one?

Hi.

I'd like to further encourage finishing this work on finer permission control.

It appears that this is an issue that probably blocks us from upgrading, as we are dependent of the workflow permissions plugin long as this remains incomplete, and bulk operations are also in use.

Power to you. Keep up the great quality and reliability.

Cheers,

Kalle Hallivuori / Sulake IT Support

FWIW, the status on this is as follows.

We did some work to allow this in 3.6. About halfway we realised this introduces a whole extra layer of complexity to bulk operations, particularly bulk move, which we wouldn't have time to address in the 3.6 timeframe. I can't say when we'll get to this again, but since a fair bit of work has been done already it shouldn't be in the too distant future.

Oops, I just found out that my request was actually a duplicate of JRA-4050 and thus is possible in the Enterprise version so please disregard my previous comment.

I would like to enforce that only the person that has created an issue or the projectadministrator is able to close an issue. I can't think of a way how to do this now in Jira (we have 3.6.1 Enterprise) and it seems that an implementation of this issue would possible enable this so my vote is in.

Adding a note here just in case: Current workflow based plugin has a bug that disables sub-task editing. For more info, see http://jira.atlassian.com/browse/JRA-10057

It will be possible to restrict permissions per workflow step in 3.6, by adding 'properties' to workflow steps. Eg. by setting 'jira.permission.editable.group' to 'jira-developers' in the 'Resolved' step, only jira-developers will be able to edit resolved issues. It will also be possible for parent issues to restrict permissions on their subtasks

There won't be a pretty interface for setting permissions per step in 3.6, so I'd hesitate to call this feature 'done' just yet.

Under workflow, transition, it is possible to define who is allowed to do this transactions by adding a condition to the transition. Would it also be possible to define the team that can be assigned to this issue in the new state.

The current permission scheme is not flexible enough. For instance: someone should be able to reopen an issue but not resolve it (Q&A department for instance).
See also JRA-5783.