Created attachment 763020 [details] GRE Description of problem: GRE constraint operator list box problems when re-opening file. When I re-open the rule that the constraint is no longer less than but has reverted to --- please choose --- And the drop down box only has four choices Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Create a GRE rule 2.Add a condition with a constraint with a literal value, for example field less than value 3.Save the file and re-open it Actual results: --- please choose --- Expected results: less than Additional info:
This has been wrongly filed for BPMS. Moving to BRMS.
*** Bug 994476 has been marked as a duplicate of this bug. ***
This affects numerical field constraints. For a quick demonstration, open Bankruptcy history in mortgages project.
String fields are affected too: - When using "greater than" or other comparing operators or "matches" and "sounds like", the select box is reset to "--- please choose ---" after reopening the rule. With both String and numerical fields: - When using "equals to" the operator is reloaded correctly however the select box options are reduced to "equals to", "not equals to", "is null" and "is not null". - "is null" after reopening: field [equal to] [Choose ...] (expression builder), similarly with "is not null". In most cases the "cursed" operator usage is indicated by alert "Are you sure you want to discard unsaved data?" showing up even after saving the changes.
Fixed in ER3.
The issue recurred in ER4. It now affects <= and >= operators.
Fixed in ER5.
This happens again with Number. Steps to reproduce: 1. Add Number to [when] section, add restriction using the expression editor. 2. Choose intValue. 3a. Choose 'greater than' operator. OR 3b. Choose 'equals' operator. 4. Type in a literal value, save, reopen. For 3a, the operator is reset to '--- please choose ---', for 3b, operator stays the same. In both cases, operator options are reduced to 'equals to', 'not equals to', 'is null' and 'is not null'.
Scenario described in comment 15 now works as expected.