Bug 1126779

Summary:	Name collision between Process variable and Script Task variable
Product:	[Retired] JBoss BPMS Platform 6	Reporter:	Anton Giertli <agiertli>
Component:	Documentation	Assignee:	brms-docs <brms-docs>
Status:	CLOSED EOL	QA Contact:	Lukáš Petrovický <lpetrovi>
Severity:	medium	Docs Contact:	Dawn Eisner <deisner>
Priority:	medium
Version:	6.0.2	CC:	brms-docs, kverlaen
Target Milestone:	---
Target Release:	6.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-27 19:40:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Anton Giertli 2014-08-05 09:14:33 UTC

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):
 bpm 6.0.2

How reproducible:
always

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";
kcontext.getKieRuntime().insert(person);

4. Save the process

Actual results:

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"
Expected results:

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.


Additional info:
Issue can be solved by renaming one of the variable.

Comment 2 Kris Verlaenen 2014-08-18 08:26:16 UTC

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?

Comment 3 Maciej Swiderski 2014-09-01 17:29:38 UTC

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.

Opinions?

Comment 4 Jiri Svitak 2014-09-02 09:04:37 UTC

Hello Maciej,
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.

Comment 5 Kris Verlaenen 2014-11-25 23:52:04 UTC

Making this a documentation issue, see comment 3

Comment 9 Kris Verlaenen 2015-05-07 20:13:21 UTC

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.