Bug 1248986 - DataIOEditor dialog remembers old process variables as Source or Target options
DataIOEditor dialog remembers old process variables as Source or Target options
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Designer (Show other bugs)
Unspecified Unspecified
high Severity high
: ER4
: 6.2.0
Assigned To: Tihomir Surdilovic
Kirill Gaevskii
Depends On:
  Show dependency treegraph
Reported: 2015-07-31 05:33 EDT by Jeremy Lindop
Modified: 2018-01-30 18:39 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Assignments after process variables renaming (6.26 MB, application/octet-stream)
2015-10-21 08:50 EDT, Kirill Gaevskii
no flags Details

  None (edit)
Description Jeremy Lindop 2015-07-31 05:33:41 EDT
Description of problem:
DataIOEditor dialog remembers old process variables which have been edited or deleted.

Version-Release number of selected component (if applicable):
6.3.0 community (version which uses the new DataIOEditor dialog for editing DataInputs/ Outputs / Associations).

Steps to Reproduce:
1. Create a new BP
2. Add a new process var "myvar", datatype "String"
3. Add a User Activity
4. Create a DataInput called "myinput", datatype "String", with source "myvar"
5. Change the name of the process var "myvar" to "yourvar"
6. Edit the Associations of the User Activity
7. The Source of "myinput" is still set to "myvar" and "myvar" is listed in the drop-down.
Comment 3 Kirill Gaevskii 2015-10-21 08:47:54 EDT
Works good, but I have a little remark.

Assignments property and Source code of elements remembers old process variables which have been edited or deleted. You need to open Assignments and save it without any changes or save whole project and reopen it. For clear incorrect link. see Attachment.

Also bug 1273871 was opened.
Comment 4 Kirill Gaevskii 2015-10-21 08:50 EDT
Created attachment 1085118 [details]
Assignments after process variables renaming
Comment 5 Jeremy Lindop 2015-11-11 12:33:34 EST
The behaviour in the DataIOEditor is improved, in that it doesn't remember the old process variable that was renamed.

Kirill - as the behaviour reported in the BZ is fixed, and you've opened https://bugzilla.redhat.com/show_bug.cgi?id=1273871 for the more general problem of process variable renaming, can we close this BZ?
Comment 6 Kirill Gaevskii 2015-11-12 05:47:21 EST
Hi Jeremy,

remaining things are relate to this issue not to new one. But you are right if new one will be fixed this issue also will be resolved. So we have two options for 6.2 release: to finish this one and fix new one for next releases or close it and concentrate on new issue.
Comment 7 Jeremy Lindop 2015-11-12 06:44:43 EST
Kris - will you take a look at this and decide what we should do for 6.2?

The underlying issue is that when the user renames a process variable which is linked to a DataInput, the sourceRef of the dataInputAssociation isn't updated, so it still refers to the old process variable, which is now invalid (https://bugzilla.redhat.com/show_bug.cgi?id=1273871).

The bug I reported here and made the commits for is that after renaming the process variable, the DataIOEditor still showed a link to the old process variable. The fix involved removing the link to the old process variable when the DataIOEditor is opened. This is a limited fix.

To fix the issue fully, we'd need to update all references to process variables whenever a process variable is renamed, i.e. fix https://bugzilla.redhat.com/show_bug.cgi?id=1273871

I spoke to Tiho about this and he indicated that resolving this is not a minor thing. That's why I wonder whether we should close this BZ for 6.2 and fix BZ1273871 for the next release.

Note that this isn't a regression. This behaviour was present in bpms6.1.
Comment 8 Kris Verlaenen 2015-11-23 10:30:25 EST
I suggest we close this one of as a sufficient (temporary) fix, and keep the other one open until we implement full refactoring support.  So putting back to ON_QA, so they can close this off as verified for 6.2, wdyt?
Comment 9 Kirill Gaevskii 2015-11-23 10:46:47 EST
OK, let's do it in this way.

Note You need to log in before you can comment on or make changes to this bug.