This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1023126 - Saving Guided Rule with uninitialized field values causes errors after reopening
Saving Guided Rule with uninitialized field values causes errors after reopening
Status: CLOSED CURRENTRELEASE
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.0.0
Unspecified Unspecified
unspecified Severity high
: ER5
: 6.0.0
Assigned To: manstis
Jiri Locker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-24 12:48 EDT by Jiri Locker
Modified: 2014-08-06 16:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-06 16:19:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Guieded Editor with uninitialized fields before save (28.07 KB, image/png)
2013-10-24 12:53 EDT, Jiri Locker
no flags Details
Source generated from uninitialized fields (18.43 KB, image/png)
2013-10-24 12:53 EDT, Jiri Locker
no flags Details
Guieded Editor after reopening the rule (18.49 KB, image/png)
2013-10-24 12:54 EDT, Jiri Locker
no flags Details

  None (edit)
Description Jiri Locker 2013-10-24 12:48:53 EDT
Description of problem:
Leaving field values uninitialized doesn't seem to be invalid. There is no UI warning. If the rule is saved in this state, the generated DRL source will have syntax errors and the rule will not reopen correctly in Guided Editor. Some elements will appear different than before saving, some elements may disappear completely.

Version-Release number of selected component (if applicable):
ER4

How reproducible:
-

Steps to Reproduce:
1. open no NINJAs rule in mortgages project
2. add amount and explanation fields to LoanApplication [app]
3. set "equal to" operators
4. bring up the input boxes for literal values, don't type any values
5. click into input box for amount field and then to explanation input

Actual results:
When amount input box loses focus, "0" value appears automatically. Looks like a sensible default value. The explanation input stays empty, which also makes sense -- the author may want to test the field against en empty string. However, when you switch to Source tab you will see:

app : LoanApplication( == null , == "null" )

You may miss this and save and close the rule. When you reopen it you get modal error message "Could not find the type for variable app". The rule will appear with errors in RHS and different LHS, see attached screenshots.

Expected results:
Saving the rule should never break it. Either the save could be denied if validation fails so the user would be forced to save it in a valid state, or better, the invalid/incomplete parts of the rule should be ignored. In that case unfinished parts would be lost after closing the editor but the rule would open in a correct state without losing or modifying any elements that were valid before saving.

Additional info:
Compare the screenshots of GRE before and after save carefully. Not only that "There is a LoanApplication [app] with:" element is crippled, the second conditional element "The following does not exist: There is an IncomeSource" is missing completely.
Comment 1 Jiri Locker 2013-10-24 12:53:11 EDT
Created attachment 815850 [details]
Guieded Editor with uninitialized fields before save
Comment 2 Jiri Locker 2013-10-24 12:53:52 EDT
Created attachment 815851 [details]
Source generated from uninitialized fields
Comment 3 Jiri Locker 2013-10-24 12:54:52 EDT
Created attachment 815853 [details]
Guieded Editor after reopening the rule
Comment 5 manstis 2013-10-25 11:24:22 EDT
Two improvements have been made:

(1) Don't render incomplete constraints when building DRL

(2) Explicitly set initial value when adding literals (which should have been happening anyway but was bugged).
Comment 6 Jiri Locker 2013-12-17 08:56:48 EST
Michael, thank you for this fine fix, it makes GRE more foolproof and reliable.

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