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?
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.
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!
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.
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. :-)
Did you know that penalties up to 4 % of the yearly company turnover are possible in case of GDPR violations? GDPR regulations are currently mainly relevant for companies in the EU, but countries lik...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events