Bug 1023126 - Saving Guided Rule with uninitialized field values causes errors after reopening
Summary: Saving Guided Rule with uninitialized field values causes errors after reopening
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER5
: 6.0.0
Assignee: manstis
QA Contact: Jiri Locker
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-24 16:48 UTC by Jiri Locker
Modified: 2014-08-06 20:19 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-08-06 20:19:46 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1009385 0 medium CLOSED Invalid Guided Rule reopens with a different definition 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1052269 0 medium CLOSED Guided rule editor: rule with incomplete String constraint reopens with different definition and elements missing 2021-02-22 00:41:40 UTC

Internal Links: 1009385 1052269

Description Jiri Locker 2013-10-24 16:48:53 UTC
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 16:53:11 UTC
Created attachment 815850 [details]
Guieded Editor with uninitialized fields before save

Comment 2 Jiri Locker 2013-10-24 16:53:52 UTC
Created attachment 815851 [details]
Source generated from uninitialized fields

Comment 3 Jiri Locker 2013-10-24 16:54:52 UTC
Created attachment 815853 [details]
Guieded Editor after reopening the rule

Comment 5 manstis 2013-10-25 15:24:22 UTC
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 13:56:48 UTC
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.