I came across this because I'm wondering if it's related. A few sprints/weeks ago we decided to name our sprints the same across all three projects because we are all working on the same business initiatives but the product teams are split by mobile, web, and api. Initially when I made this change there was a small conflict where, when assigning an issue's sprint we had to select the right one. Although this was not ideal it seemed with the pain compared to having three separately named sprints that all technically relate to one another.

Now, today we are seeing strange (but seemingly good behavior), now while on the mobile or web project all issues only have the API board's instance of the sprint (even when selecting "Only show sprints in this project"). 

This was really confusing because we can't seem to select the proper sprint as we did just weeks ago, BUT this is actually one step closer to our ideal solution which is just selecting "FMH Sprint 6" and not having it presumably associated to a specific board. Each board already filters the issues according to their project as expected so this appears to work (apart from the "API board" confusion).

For a moment it appeared the board was working but the backlog wasn't, but today it appears the backlog is working now as well. We are monitoring this closely because on any given day issues can disappear from view and our devs will ask for more work even though the issue itself still exist as expected.

Hope this helps with some feedback. As I mentioned, whatever you're doing it's one step closer to what our organization needs  

FWIW we prevent the move of a Story/Bug assigned to a Sprint to another Team (using a Team field) using Automation.

+1

is there a way to +1k for this? 

Such a pain point for our organization.  We've been dealing with this issue for months without resolve and lost our Jira Admin in the process.

Please, Atlassian.  Fix this issue as it is more than a "bug".

Hello everyone, I see there have been a lot of workarounds involving modifying the offending issue or reopening and closing the sprint, which is not always possible or straightforward since it may involve another team's closed sprint, and you could break another team's velocity chart or sprint history in order to fix your own. 

Instead of trying to fix the offending issue and sprint, I flipped my logic to fixing my board. 

I reconfigured my agile board's filter to exclude the sprint values which came from another project, here is an example:

(project = X AND Sprint not in (1234)) OR (project = X AND Sprint is EMPTY) ORDER BY Rank ASC

The first section of the filter before the OR statement searches for all issues in sprints except for the one that I want to exclude.

The second section includes the backlog. 

I hope this helps, as this issue is incredibly frustrating! Hopefully Atlassian can fix this bug soon so that we don't need to keep inventing new workarounds when they stop working!

+1 for this request.

This is a huge deal for our organization.

Ideally, if you could pop up the sprint field on the Move screen like you do for some other fields and allow the user to clear it or keep it when moving, that would solve so many problems.

I've had to write FAQs, documents, have meetings, we've had at least 100 support tickets submitted to us related to this problem, and even then some people still don't know that they're shooting themselves in the foot when they move things that already belong to sprints.

I love the ability to have cross-project sprints, but we need to make this a little more fool proof or confusing. Allowing for the field to be displayed when moving an issue if the field is populated to give the user the option to keep or remove would be so very helpful.

Please consider fixing this behavior as it's leading to data corruption.

Thanks!
Kim