-
Suggestion
-
Resolution: Duplicate
-
None
For an enterprise level user like us JIRA 3.5 's missing granularity in permission schemes is a hard blocker — --- and there is no work-around.
There is a related recent issue here: JRA-5865. We voted for it.
But Atlassian's comment to it makes us believe that this issue does not get the priority it deserves.
That is why we would like to provide more detail and background:
==================================================
Like most enterprise project owners, we need to assign permissions per project, per group, per issue type.
(Even your average CMS can do this today.)
Want a typical example ?
4 weeks ahead of a release deadline, the project manager wants to focus his/her developers on "wrapping up" and "cleaning up" tasks, and TEMPORARILY prevent them from creating or working or resolving certain issue types, like "new features", which can be resumed AFTER the release.
Currently, JIRA cannot do this.
And what makes things worse: there is no work-around:
As far as I can see after several trials, none of the many Jira scheme mechanisms can help to implement such local temporary changes of project configuration:
- the change of permission scheme cannot be done on a per issue type basis
- theoretically, a bulk operation to change the priority of certain issues could be done, but this is irreversible and cannot prevent developers
- preventing visibility through the issue security scheme is neither practicable nor desirable
- when changing the workflow scheme, JIRA forces an irreversible status conversion (understandably)
- changing the issue type scheme forces an irreversible conversion of existing issues to the new scheme type (looks like a JIRA conceptual flaw)
- also the issue type screen scheme is of no help, because it does not include control over functions like "resolve" (looks like a JIRA conceptual flaw).
Does anyone know a workaround to "emulate" permissions per issue type ?
- duplicates
-
- Closed
- is related to
-
- Closed
Hi Wolfgang,
Thank you for your comments and explanations. They definitely help us understand why a feature is important.
I think the issue with the last 2 points that you identify as a 'conceptual flaw' is that they were not built to address permissions per issue type.
The way that we address the situation internally, is that the fix for version and due date fields are protected by Resolve Issue and Schedule Issues permissions, respectively. Generally only people that have the authority to plan a release have permissions to set these fields. It is the responsibility of these people to schedule bugs to the next version and treat Feature Requests according to where the release cycle is at.
However, in your case you can grant the Resolve and Schedule issues permission to more users at the start of the release cycle and then narrow it down as the version nears a release. This does not allow permissions per issue type, but with the Bulk Edit feature it is not difficult to schedule all recently created bugs onto the next version in one go.
While this does not stop issues from being created, it does ensure that the issues are scheduled correctly. This also ensures that the issues are created and the information is captured in a timely fashion, and is not delayed until a release is out.
I hope this information helps.
Also thank you for voting for
JRA-5865. As far as I can tell,JRA-5865is exactly what you are looking for, and voting for that issue and providing reasons for why you think the feature is important is the best way to influence our scheduling process. For more information on how Atlassian schedules new features please see:http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements
I will resolve this issue as a duplicate of
JRA-5865as we aim to have one issue track progress on a Feature Request to avoid scattering of information.Thanks,
Anton