Hi everyone,

As rkrishna said a couple years ago, we are interested in simplifying this area of JIRA before we add more functionality. Layering permissions across individual transitions would make JIRA workflows an order of magnitude more complex. Our focus, as a product, is on making JIRA's workflow and permissioning model simpler. I do not expect us to implement this in the foreseeable future.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

For some transitions we use specific groups to resctrict the permission,
e.g.:
Step Integrated

• Transition: Verify Issue
  Only users in group jira-testers can execute this transition.

i.e. we use roles and groups to define permissions.

You can implement this feature using 2 steps:

• create a group (or a role) that includes the members that hold this rights (e.g. "Promote Issues to Test").
• use SIL function userInGroup to write your transition condition like this:

if(userInGroup("Promote Issues to Test",currentUser())) 
   return true;
else
   return false;

Simple Issue Language is meant to simplify your special processsing in conditions, validators or post-functions.
The code above has the same behavior as requested, except it is only for the transition it is implemented for.

Give it a try here: https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin
or here http://jira-plugins.kepler-rominfo.com/x/product/id/3

Here is how you create a condition, validator or post-function: http://confluence.kepler-rominfo.com/display/JJUP20/Writing+Validators%2C+Postfunctions+and+Conditions

My use case is as follows. I'm trying to implement a mechanism to delegate issues to a group. So, I've created an Assigned Group custom field. Assignation to a group happens by a workflow transition. This transition clears the assignee, with the understanding that someone in the Assigned Group will pick up the ticket and then assign it to themselves. However, I don't want members in the Assigned Group to be necessarily able to assign the issue to another group. So, I need new permission, something like Delegate to Group that permissions the workflow, and it must be separate from the Assign Issues permission.

Thanks for the recent comments.

At this time we do not have any plans to add this feature to our roadmap over the next 12 months. Adding custom permissions to custom workflows would add another layer of complexity to the admin section. Right now we are working on simplifying this area before we add further functionality. If you are interested participating in this new project you might like to take a look at the following prototype plugin.

Sorry that we have not made any updates to this issue in such a long time.

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

I would also like to hear the status of this feature. It's been a long time since anyone from Atlassian has commented!

Hi,
We are also having same requirement.Is there any update on this issue.
If you have a solution it will be helpful to us.
Thanks

Any updates on this issue, we could use this feature and not having it poses a risk that someone might act on a issue that they shouldn't be able to.

Hi! Jira is a great concept, but some impossible little features do this system inflexible and clumsy. I suggest that You working only with top voted issues. But a lot of issues with no top votes are important for us, and for another users. I'm your client - and I'm pay for support not top voted issues, but for my important issues.

Ability to add custom permissions to any permission schemes would make it easier to create secured plugins.

E.g. I'm in the process of developing an issue operation plugin. It would be great if admins were able to restrict access to this issue operation via custom permission in the permission schemes.

It would be very much more intuitive to manage access to plugin functionality in permission schemes instead of having to hardcode / configure Project Role names in plugin modules.

Being able to create custom permissions, a plugin could perform checks like
isUserHasPermission(user, "<name of custom permission>")
instead of
isUserHasRole(user, "<name of project role>")

> When exactly is it going to be fixed?????

Dmitry, unfortunately we do not have a date for the implementation of this feature.

Having said that, in JIRA 3.7 the addition of Project Roles should help with this problem. It is possible to restrict a workflow transition to a particular project role. The members of the project role can be configured per project, and therefore it is possible to use the same workflow across different projects.

ok, so we are closing on 4 years on this issue. there is a lot of interest, it seems for it to be fixed. When exactly is it going to be fixed?????

I second Christopher. Could someone please update this issue? Is this at the bottom of the queue?

Thanks,

Hongbo

Hi everyone,

last updaten on this Issue is now 1 year in the past. Would be very nice if this could get implementet very soon.

Thanks

Christopher

Greg,

Unfortunately at the moment there is little more we can say about this. We are currently trying to work through issues in order of their popularity. Please bear with us.

Thanks,
Anton

Can somebody please provide an update on where this issue is at. It was logged two years ago and has not been assigned to anybody or scheduled for release.

Sorry Greg,
I think Nyree's comment above confused me.

Their comment (and mine) has to do with "Permission Types". Ie. The values you can select for a Permission. E.g "Current Assignee", "Reporter", "Project Lead"....

You can not add new Permissions through this method.
Once again, sorry for the confussion.

To add your own Permissions, you would need to modify the source.

Cheers,
Nick

Hi Nick,

Any chance you could point me in the right direction on how to add custom permission through the use of SecurityType. I have had a look at the code but it is not immediately obvious.

I want to add a number of permissions, each relating to a custom workflow step that has been introduced.

Greg.

It is possible to create your own permission types at the moment.

Though it does require some programming.

You need to create a class that implements com.atlassian.jira.security.type.SecurityType

Once you have placed this in the class path, all you need to do is edit the file:
WEB-INF/classes/permission-types.xml

to include this new type.

I know it is not the solution but it is a workaround for the time being.

Cheers,
Nick

Any idea when this is likely to be included. There seems to be a reasnable amount of interest from others and it was logged nearly two years ago. A fix version would be helpful.

Nyree,

That is a bit of a separate issue - I've raised it as http://jira.atlassian.com/browse/JRA-7272

Cheers,
Jeff

One additonal improvement to conditions, permissions and customisations to workflows would be to allow combinations of transition conditions to use AND, OR and NOT logic.

Presently, each time a condition is added to a transition, Jira uses the AND logic.

Two additional handy conditions would be:

"progressor belongs to same group(s) as:

• reporter
• assignee
• resolver"

and

"User is NOT in Group"

These permission/conditions would of course have to be applied with care (for a reporter, assignee and resolver can and often do belong to multiple groups).

The permission and conditions could be implemented as customisations, but it would be much nicer if they came standard.

I totally agree with Dan! To update a workflow to include a new group every time a new project is created is too cumbersome.

Of course, the "User Is In Group" workaround doesn't cut it if you want to have multiple projects use the same workflow with different groups. You would have to be willing( and able ) to create a custom workflow for each project. That's where user defined permissions would be extremely nice.

It means adding a Condition to the workflow transition, stating that the user must be in group X before they can see or make that particular transition. This is effectively what permission schemes do, although they provide a layer of indirection.

Can you please explain what you mean by "User Is In Group" work around.

A more general workaround for this is to use the "User Is In Group" condition to enforce security.

The suggestion of custom permissions, is a very good one, though. The implemtation of this will be somewhat complex, however, and I am afraid we will not have time to address this for JIRA 3.0 final.

I would be very interested to see how popular this issue will become (i.e. how unsucessful the "User Is In Group" workaround is). Depending on the relative popularity of the issue we could address this in JIRA 3.1.

Yes, that would be very helpfull.
Any idea in which version this will be added?

This Issue (JRA-2041) has not been fixed but should be fixed as part JRA-2753. If you can create Custom Permissions and assign them to Custom Workflow Transitions then this Issue would be resolved.