|
Yes, that would be very helpfull.
Any idea in which version this will be added? 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. Can you please explain what you mean by "User Is In Group" work around.
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.
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.
I totally agree with Dan! To update a workflow to include a new group every time a new project is created is too cumbersome.
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:
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. Nyree,
That is a bit of a separate issue - I've raised it as http://jira.atlassian.com/browse/JRA-7272 Cheers, 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.
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: to include this new type. I know it is not the solution but it is a workaround for the time being. Cheers, 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. 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. To add your own Permissions, you would need to modify the source. Cheers, 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.
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, 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 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?????
> 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. 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
Ability to define custom permissions to support custom workflow
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.