Description
Issue Summary
This was discovered while testing for, and is somewhat related to JIRAALIGN-4861. If an Epic is moved to in progress by a child story, the inProgressDate is recorded (though incomplete).
If the parent epic is then moved back to not started, and then later changed to in progress by a child feature, the inProgressDate (as pulled by the API) is not updated. The date remains the same as it was set when the story changed the Epic to in progress the first time.
Steps to Reproduce
- Find a new epic that has child features and stories, but nothing is in progress yet.
- Change on of the child stories to in progress and make sure that the parent epic was also moved to in progress
- Do an API GET on the epic ID from step 1. Make note of the inProgressDate.
- Manually set the epic back to not started.
- Change one of the epics child features to in progress. Make sure that the epic was also changed to in progress.
- Do an API GET on the epic ID again.
Expected Results
The inProgressDate timestamp should be updated to match the 2nd transition to inProgress by the feature.
Actual Results
The inProgressDate is not changed. It still shows the date that was set by the first story transition.
As with JIRAALIGN-4861, the in progress date captured by epic export is correct. The date returned by the API is incorrect.
Workaround
No known workaround. The dates are set correctly if the Epic is set to "in progress" manually in the UI, but this isn't a feasible workaround.