-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
7.2.4
-
Severity 3 - Minor
-
0
Issue Summary
The "If issue type" conditions (and probably others, but this is the one I use most) end up with the wrong issue types when moving between environments whose IDs don't match. This is going to be common when creating new issue types in a test environment before going live in Production, and the identification should be more robust, checking that the name of the issue type (or other field) matches what was exported upon import, and finding a match if the ID and name don't both match, perhaps even asking for what that ID/name should map to in the new environment. Customer had to update every rule individually to correct this after my last import.
Steps to Reproduce
1. Refresh Dev environment from Prod so they match 100%
2. Create two new issue types
3. Create an automation rule with a condition that requires one of those two new issue types in Dev
4. Export the rule from Dev
5. Create the two new issue types in Prod, possibly in a different order (because of using Project Configurator to move the issue types between environments)
6. Import the rule from the file
Expected Results
No matter what order the issue types are created in, the rule is correct, or alerts the user running the import that the issue types in the target environment (Prod) don't match what was exported from Dev
Actual Results
The rule may silently refer to the WRONG issue type without any indication of what happened unless you're looking for it.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available
- links to
- relates to
-
A4J-2697 Loading...