|
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. 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
 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.
Oops, I just found out that my request was actually a duplicate of
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. 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 A lot of votes...
I know you guys are very busy and there are other pressing issues but any status update on this {big} one? 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
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 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? 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. 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 ? my new corp id is monika.joshi@corp.aol.com , Pls send all your mails to my new corp id
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. Sebastian you rock
thanks a lot , i'll use it I'd be very interested in setting up a situation where you cannot comment on a closed issue!
We would very much like to restrict the ability to comment based on workflow state.
Jeff. 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.
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. 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.
Lieber Mail-Sender
Bis zum 05.01.2008 weile ich ausser Hause und werde keine Email lesen. Mit freundlichem Gruss und besten Wuenschen fuers Neue Jahr Erwin Achermann 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.
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.
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:
Gilles,
I tried defining the assignable group in the properties of the Thanks........Susan Susan,
The jira.permission.* and jira.issue.editable properties only work on workflow steps and not on transitions. Hope this helps. Thanks!!! Got it to work....
Where is the list of "properties" that you can define in JIRA? These Susan 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. 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. We realy need this function to prefent customers from commenting on closed issues. Is there some workarround for this?
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Permissions per workflow step / state
Any news guys?
See also JRA-5783.