Steps to reproduce:
Create a global rule using the issue move trigger.
In the move trigger, set the project to a single specific project. (project key 'XYZ')
Publish the rule.
From the automation list, click the … to the right of the rule and copy or move the rule
In the copy/move, put the project into a single project context that is not the same as the specific project that the issue move trigger is currently set to. (project key 'ABC')
What should happen:
The issue move trigger's `to` field should be changed to match the new context of the rule. (ABC)
The rule will appear to be in good shape. Rule details will show that the rule is in the ABC project context. The issue move trigger will show that the `to:` field is set to ABC as well. However, in the database the `to:` field will still be set to XYZ. This causes the rule to never execute.
This bug shows multiple problems, all of which should be considered in fixing this:
The Automation UI shows the incorrect details in the `to:` field for the issue move trigger when the rule is a single project rule.
When a rule has a single project context, the move issue trigger executor should always use the rule context instead of whatever project is in it's `to:` field.
The copy/move operation may need to be aware of the issue move trigger and update it's `to:` field.
Making the copy/move operation aware of specific components is a bad idea from a platform perspective. We can't expect it to grow infinitely in it's awareness of corner cases from specific components. For this reason, the first two fixes are preferable.