|
History
| Log In
|
|
|
|
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Permissions per workflow step / state
Any news guys?
See also JRA-5783.