I get that this is a weird situation. I'm trying to build a use case scenario where an alternative step can merge back into the main line. Let me draw you a picture:
Primary Step 1 ---> Primary Step 2 ---> Primary Step 3
Primary Step 1 ---> Alternative Step 2 --> Merged to Primary Step 3
The UseCaseStep BO has a PreviousStep single attribute, a pm_NextStep many attribute, a NextStepCount number attribute, and a MergeToMainPath single attribute among others.
Whenever I have a new/moved Primary Step 3 (or higher), a rule triggers to look back two steps and forward one step to update the alternative steps to merge to that step. That rule (UseCaseStep.PreviousStep WAS CHANGED) triggers. But when an alternative step is created/moved (which triggers the NextStepCount for its PreviousStep reference to be changed), the following rule does not appear to trigger:
If UseCaseStep.PreviousStep.PreviousStep.NextStepCount WAS CHANGED AND [other stuff] Then
Can AIM look beyond one reference to trigger a rule? I could see if that were not the case. What I'm trying to do is a little odd. I just need to know so I can give up trying and find another solution.
And if that's not the case, does anyone know an elegant solution to this problem? If I work from the alternative step (which will easily trigger), in order to update MergeToMainStep, I have something like UseCaseStep.PreviousStep.pm_NextStep.pm_NextStep, which won't work because of the many manys. I can break that up into separate Find...Wheres, but then I have a problem with the context because I've used up the "This" (new/moved alternative step) and "That" (first Find...Where...TAKE BEST 1) prefixes and need something like a "3rd" or "Last" prefix for the 2nd Find...Where...TAKE BEST 1.
Maybe I just need to create an extra attribute that refers to the primary next step. Ugh.
