Issue Summary

When a sprint is completed, and incomplete issues are bulk-moved to a new sprint, the created timestamp on the Sprint field changelog entries is incorrect. Instead of recording the actual time of the operation, each entry inherits the timestamp of the previous unrelated changelog entry on that specific issue, down to the exact millisecond.

Steps to Reproduce

1. Have a project with a large backlog and issues with the existing changelog history.
2. Complete an active sprint that contains a large number of incomplete issues (typically > 250 issues to trigger the bulk path).
3. Choose to move the incomplete issues to a new or existing sprint.
4. Check the History tab or the Changelog REST API for the moved issues.

Expected Results

The Sprint field changelog entry should have a timestamp reflecting the time the bulk move/sprint completion occurred.

Actual Results

The Sprint field changelog entry shows a "bogus" timestamp that matches the updated timestamp of the issue's previous history entry. This can result in sprint assignments appearing to happen months or years before the sprint was even created.

Workaround

There is currently no known workaround to prevent this during bulk moves. Single-issue sprint assignments are not affected as they use a different code path.