Description of problem:
Variable with the same name as Process Variable can't be used in the Script Task.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create new process, start-->script-->end
2. Create process variable person:String
3. Add following code in the script task:
String person = "abc";
4. Save the process
If script task includes variable with the same name as one of the process variable,following exception is displayed and process can't be saved:
"Process Compilation error Duplicate local variable person"
Script Task has it's own variable scope which should not interfere with any of the 'external' variables definition. The above process definition should get compiled without any issues.
Issue can be solved by renaming one of the variable.
This is the result of auto-injecting variables into scripts. The script has its own variable scope, but since known variables are auto-injected, this will still introduce a conflict if you try to redefine the same variable name locally. Not sure what the solution should be for this, as auto-injection of variables is an important feature, maybe better validation / error messages?
Took quick look at what we have there and not sure we can do much improvements there. In my opinion we already provide valuable and meaningful error message when same name is used for local variable within script as for process variable.
Introducing variable scope for script task won't change much unless we start doing variable mapping to other names for process variables. That will make life of a user much more difficult while working with scripts.
To sum up, I would vote for keeping it as is now and document that local variables cannot be names same way as process variables. There is a contextual help with ctrl+z to suggest process variables so it's easy to know what names are already taken.
Your comment makes sense to me. I find the current behavior satisfactory and the requested change would cause worse user experience.
However I was not aware of Ctrl+z option, so I would suggest to close this bugzilla and probably file a new documentation bugzilla to update docs if there is a missing/incomplete description of this topic.
Making this a documentation issue, see comment 3
Variables do exist in their own scopes. However, to avoid users having to look up variables etc., we will automatically inject (a copy of) known variables into the local scope, so they can easily be accessed. This however means that you then can't define another local variable in the script with the same name.