Restrict user to move issue into a project

[Rahul Aich [Nagra]]

Hi

I want a user to be able to create issue in my project but not allow him to move an issue from another project to my project.

How is this possible.?

I know that Move operation also depends on create issue permission so i cant achieve this out of box.

Rahul

[Nic Brough -Adaptavist- · Accepted solution]

That's a really good one.  Although I suspect the use-case is pretty much "ask your users to stop being a bit silly", there's actually no way to do this off-the-shelf, and I can't think of a way to block it without code.

The problem is that I can't think of any way to block the move - it doesn't actually execute the "create" transition, so you can't plumb any code into transition functions to block it.  That means you're going to have to dive into the core code in JIRA to change the permission checks that "move" does.  Or disable "move" and write your own addon to do it

[Daniel Bower]

I'd also like this functionality. It seems there isn't very much control around moving issues. It would nice to have transition-like controls in place. It's wishful thinking to be able to ask users to not be "silly". I'd like to be able to use a post-function that says "If custom field X = Value A, then do not allow Move". In our use case, customer-reported issues should always remain in our maintenance Project, but we'd still like the ability to move internally-reported issues out of the Project, as well as internally moving issues within the project.

[Nic Brough -Adaptavist-]

Why would you want to stop someone moving an issue into a project, when they have the right to create in there? They'll just get annoyed and either not bother to do anything, or they create a copy, probably missing information including where it came from. (That's the "silly" bit, the "prevent user from moving an issue out of a project" you describe is perfectly sensible. But sadly, not implementable in JIRA)

[Daniel Bower]

In this case, there's a maintenance project and a new development project. Users should be able to create in the new dev project and move feature requests into it - but not customer issues. It's a training issue, but if we could put a control in place it would make things that much easier.

[Peter Milakovich]

I'd like to see this functionality as well.  We have users that will sit on an issue, sometimes over a year, and then say,"Oh, this belongs to another project."  They then move the issue into the project, destroying any create date to close date metrics for that project, and most of the time these folks don't even give you a clue as to what you're supposed to look at, and you're stuck sifting through a years worth of comments trying to determine what's going on.  We'd like to be able to block moves into a project, and force users to create a new issue in the project, specifically asking for what they need.  In a perfect world, all of this wouldn't even be necessary, but the reality is, you need some control.  My apologies for the long-winded rant, but the need is real.

[Nic Brough -Adaptavist-]

Take away their move rights in the source project.

[Udo Brand]

Yes, it also depends on create issue permission.

In order to move an issue from project A to project B the user needs move issue permission in project A (source project) and create issue permission in project B (target project).

So the user must not have move issue permission in all other projects than your target project. But this could be hard (or impossible, depending on the requirements in those other projects) to set up.

[satyanarayana visampalli]

Hi Rahul,

Move operation doesnt necessarily depend on Create issue.

The way I used Move Issues permission is I created a Role called "Multiple Leads" and assign the users to Leads so only Leads can move issues not all the users but any user can create issues in my project.