]
Michael Anstis moved GUVNOR-2164 to DROOLS-1785:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-1785 (was: GUVNOR-2164)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Guided Decision Table Editor
(was: Guided Decision Table)
Affects Version/s: 6.1.0.Final
(was: drools_6.1.0.Final)
Guided Decision Table editor does not allow proper operators after
editing a BRL clause
---------------------------------------------------------------------------------------
Key: DROOLS-1785
URL:
https://issues.jboss.org/browse/DROOLS-1785
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor
Affects Versions: 6.1.0.Final
Environment: RedHat Linux 6.3 x86_64; firefox 10.0.5
Reporter: Stephen Slaboda
Assignee: Guilherme Carreiro
Labels: decision_table, drools-wb
Attachments: exampleModel.png, occurrenceOfBug.png,
sourceTabAfterBugObserved.png
When editing an existing BRL condition column in the guided rule editor, condition
clauses in the BRL that compare using relational operators (i.e. <, >, etc.) for
Long values (maybe other numerics as well) are reset to "--- please choose ---".
The choices then given are only ==, !=, == NULL, and != NULL.
The choices should be the same as when I first selected "greater than or equal
to" or the like, and should retain the value I originally set. Looking at the source
tab, I still see the > value. This happens with both Literal and Formula entries
(didn't try others). When initially editing the rule, this bug does not appear.
However, after closing the editor and opening the rule in the decision table editor again,
it happens consistently.
Looking at the .gdst file for the rule, I see that the <operator> tag for the
column in question is >= in order to escape the XML tag trigger. This may be a
factor in what is causing this bug. In my production environment, I am not able to make
the decision table rule fire.
If I copy the source from the decision table editor's source tab into a pure DRL
rule, the DRL rule fires just fine given the same input.