Hi there,
We are using many different jira projects to manage work for different clients. We also use many rapid boards to look at work across those projects using different filters.
Often our users can do things that unintentionally result in tasks moving from one project (the correct one) to another (incorrect one) which results in sprints from one project appearing in the backlog of other projects. Once this has happened, its quite hard to rectify - simply moving the task back to its correct location doesn't remove the sprint from the wrong project, and deleting it requirements management of all the tasks in the correct project.
Are there any tips or solutions that could help prevent the cross-contamination of projects like this?
Thanks.
Hi Phil - you might considering limiting the permissions as to who can move an issue on that project.
Just edit the Permission Scheme for that Project and change the values for Move Issue permissions.
Hi John - this could indeed be very interesting as a solution. Would removing the permission to move issues prevent a user from accidently pulling a sprint from one project into another by moving an issue in that sprint? Do you think?
And can you think of any negative consequences of making this permission change - I have some admins who could retain the permission.
Thank you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So, I am not exactly sure of the answer to your question other than to try it. There might be a difference in the terminology that we are using as well. A Move in Jira relates to physically changing the project ID associated with that issue to a new project ID.
For example, issue ABC-123 is in project ABC. But the issue is moved from project ABC to project DEF and now the issue becomes DEF-4 or something like that. Is that what you are talking about? If so, then yes, it should prevent that if you remove the permission.
Again, the best thing I can tell you is to create a test scenario and try it out. :-)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks John - I'll give it a try and see how it goes. You are right, we have to be so careful to use the right terminology when talking about complex platforms like Jira!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Ash Pitt
Good question - no, clients are not causing the problem, it tends to be internal users.
They can definitely be trained to avoid it, but even then, its a bit of an invisible problem and its not always obvious, in my opinion, when this issue will occur - until its too late.
I found the issue, and the workarounds (rather than solution or prevention) were well documented here: https://community.atlassian.com/t5/Jira-Core-questions/Why-does-moving-an-issue-between-projects-associate-the-sprint/qaq-p/1491349
I'd be happy to consider settings changes, permission scheme changes, and add-ons, if it would help this issue.
Thanks, Phil.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To @John Funk 's point - yep definitely limit those permissions on who can do what. This is also a good read on some best practices as well!
Cheers
Ash
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.