Issue Summary

When removing a program from an Epic, the Forecast data is not updated to remove the Business Epic's forecast records for that Program.

This seems to occur when the program is removed from the Epic, but a PI remains connected to the Epic that is linked to both the removed program and another program relevant to the Epic.

This is reproducible?: Yes. Please see https://alignsupport.jiraalign.com and the steps below.

Steps to Reproduce

1. Login to alignsupport as a super admin user.
2. In the Tier 1 filter, enter: "Diego Program"
3. Navigate to the Epic Grid and click on Epic ID 2788. Note the two additional programs included and the PI "DiegoReleaseADO1":
   
4. Remove "Diego Program ADO1" from the Additional Programs Box but leave the PI titled "DiegoReleaseADO1" in the Program Increments box.
5. Click Save to save the changes. You may see a warning about a PI tied to the Epic but has no program associated with it.
6. Click the Forecast Tab on the Epic and Select "DiegoReleaseADO1" from the drop down menu. Note that the removed program is still included on the forecast tab:
   
7. Navigate to the forecast page and ensure "Diego Program ADO 1" is selected for the program in tier 1 and that "DiegoReleaseADO1" is selected in tier 1 for the PI.

The Forecast page still shows the Epic listed for the program and PI:

Here are the details on the "DiegoProgramReleaseADO1" PI with regard to program associations:

Expected Results

If the program was removed from the Epic, shouldn't all traces of it be removed from the forecasting data for that Epic? Is there some other condition we've missed that will cause the removed program to still show up in the Epic's forecasting data?

Actual Results

The removed program still shows up in the forecast tab of the Epic for a given PI and the Epic is also listed in the Forecast page when filtering on a program that was unlinked from the Epic.

An older, related bug was filed here: https://jira.atlassian.com/browse/JIRAALIGN-2344

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available