Using quick filter and rapid board sprint planning together allows for many invisible issues to be accidentally committed.

See GHS-4951 for context. GHS-4951 introduced a fix with the intent to solve the problem, but the problem has not been solved for all use cases.

We hit the following behaviour at least three times: Using quick filter to remove issues from view, and dragging a visible issue above the sprint marker, seems to drag many other issues as well - presumedly the issues between the two visible issues.

This is not intuitive behaviour, and the damage can be significant. In our first case - somebody incorrectly used a filter and managed to include 600+ unrelated issues into their sprint. In the second case - I was demonstrating the new rapid board to internal customers, and even though we were trying to be careful by not moving the sprint marker (as we suspected that the original user had done) - and when clearing the filter, suddenly many issues appeared above the sprint marker as well. In the third case it also represents in hours of lost time to fix the damage.

Dragging one issue above the sprint marker is not intuitive to result in many issues being moved above the sprint marker. Can you re-open and look into this?

We have GreenHopper 5.10.3 deployed.

I recommend either:

1) Blocking the behaviour. At least this will eliminate the surprise factor and the risk of damage.

2) Re-ordering the issues to allow the issue to be moved into the scrum without also including the invisible in between issues. I understand that there is a concern that this behaviour is magical - however, I think the magic is exactly what users want to see, and they would prefer to re-rank the visible issues in committed over accidentally committing to dozens or hundreds of stories.