After moving an issue to another project, there seems to be references to the original project, as users need permissions in the original project.
How does one clear out (sterilize) these references?
One of the references that are carried over during a MOVE is the sprint (sprint marker), even if that sprint has nothing to do with the project you are moving the issue to.
Do a quick audit of open issues in both projects (to and from) and ensure that there is not a sprint marker assigned from the other projects board. Do not use a JIRA Agile board to perform this audit as you will typically have the offending issues filtered out, Instead use an issue filter, looking at open sprints, and look for one that does not belong to that project. (Hopefully you do not use short Sprint names like 'Sprint 1' on all your projects.)
I am assuming the references you are referring to here are the sprint information references and the issue links.
With sprints, you can put the Sprint field in the edit issue screens to remove the sprint field values from the moved issues.
With issue links you can directly delete the issue links to the original issue from the view issue screen of moved issue.
I'm not sure which references in the system are causing this issue. That is part of what I am asking. What fields (columns) do we needs to clean out to prevent this issue? I have already attempted to interact and clear out the Sprint field. The field does NOT include a sprint from original project, but it does in the current project. Just as a matter of trying something, we have attempted to clear out field (delete the sprint value that is there) and then re-add that sprint value. This did not work. If I need to clean out Issue links on the clones, we can try that, but what issue links are left behind on a Move? I have not noticed any.
Actually, that sounds like something is *very* broken, or you've got addons doing validation that you need to modify so they take account of the new location. If you move an issue from one project to another, then the issue will take on all the setup built into the new project. Specifically, the one thing you've mentioned is "users need to have permissions in the old project". Jira simply does not do that. Sprint fields are the only exception to this, but that's not quite broken because sprints can go across projects. So, the question now needs to change - it's not "what do I need to clear out", it's actually "what have you implemented that causes the problem". Could you describe what is happening that appears to need a user to have rights in the old project?
Here is one case and probably the easiest to describe. We have an issue documented and groomed in Project X. While it was groomed, the issue was never worked (i.e. coded, tested, deployed) and all work on Project X stopped. Later, the issue was found relavant in Project Y (an active project). Wanting to retain the grooming and documentation, we moved the issue to Project Y. We later put it in a sprint on a board that only looks at Project Y. A user, a who is an Admin on Project Y and the board for Project Y, attempts to 'move up' (re-order) the sprint(s) the issue(s) have been moved to on the Backlog screen. After a slight delay, JIRA complains that the user does not have permissions on Project Y and Project X. If I (temporarily) give the user permissions on Project X, the user can 'move up' (re-order) the sprint(s). As to what we have implemented. I'll say this. Project X is considered 'Closed' by us. We do not want anything to change on them. We have applied a Permission scheme were users can only Browse the Project and View Code changes. (i.e. do research in a read-only state) We do temporarily lift this permission scheme while someone is Moving an issue(s) out of one of these old Closed projects. Atlassian Support has suggested I do a re-index and retest and we will be doing that sometime tonight.
Nic, First, thanks for your feedback. You have given more insight into this than Atlassian Support has. In the past we have tried to remove the assigned sprint, through the UI, and then add it back. This did not work, but we gave it a try. We never saw an additional sprint value from the old project thru the UI. I'm not afraid to look under the hood into the tables directly. Is there any documentation that you can recommend for the JIRA & JIRA Agile schema?
There's not a lot of docs for the Jira Agile schema, and it has a nasty habit of changing (well, more frequently than JIRA's scheme anyway) The problem with stripping the sprint off an item is that it destroys the information that gives you the sprint metrics (velocity etc) - it's not a scenario Agile has been coded for in my experience. If you're willing to live with the loss of sprint metrics, then you will need some code. Nightmare to try it in the database (especially as you'd have to stop JIRA and reindex it after any changes), so I'd reach for the Script Runner and write something. Specifically a "listener" that would be triggered by "move" events. It can read each issue moved, check if it is changing projects (move events happen for other stuff) and then simply clear out the sprint. The only problem here is that I don't know the Afile API well enough to tell you what will strip the sprint out completely.
We eventually found the offending issues in this problem. We had moved a series of issues from Project X to Project Y. They were later put in a (placeholder) sprint on a board that only looks at Project Y. We discovered a small set of issues that were moved to Project Y in error. These were moved back to Project X without removing them from the sprint. Since the boards filter only looks at Project Y, we could not see the issues from Project X. With some work in an issue filter, we eventually found the issues in Project X and cleared out sprint marker. The user was able to perform actions on the board after this was cleared up. In the end I had the problem backwards. A references to Project X was not lingering in the issue after being moved to Project Y. Instead, a reference to Project Y (the sprint marker) was lingering in the issue after being moved back to Project X.
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs