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 ?