Bug 1248986 - DataIOEditor dialog remembers old process variables as Source or Target options
Summary: DataIOEditor dialog remembers old process variables as Source or Target options
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Designer
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER4
: 6.2.0
Assignee: Tihomir Surdilovic
QA Contact: Kirill Gaevskii
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-31 09:33 UTC by Jeremy Lindop
Modified: 2020-03-27 19:47 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:47:50 UTC
Type: Bug
Embargoed:


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

Description Jeremy Lindop 2015-07-31 09:33:41 UTC
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 12:47:54 UTC
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 12:50:55 UTC
Created attachment 1085118 [details]
Assignments after process variables renaming

Comment 5 Jeremy Lindop 2015-11-11 17:33:34 UTC
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 10:47:21 UTC
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 11:44:43 UTC
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 15:30:25 UTC
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 15:46:47 UTC
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.