Bug 1012553 - GRE doesn't handle multirestrictions when reopening rule
Summary: GRE doesn't handle multirestrictions when reopening rule
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ER1
: 6.0.2
Assignee: Toni Rikkola
QA Contact: Jiri Locker
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-26 15:55 UTC by Jiri Locker
Modified: 2014-08-06 19:53 UTC (History)
5 users (show)

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


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 968309 0 unspecified CLOSED "and equal to" option is not available in BRM (Guvnor) 2025-02-10 03:27:49 UTC

Internal Links: 968309

Description Jiri Locker 2013-09-26 15:55:25 UTC
Description of problem:
Basically the same problem as bug 975922 and bug 1000464 but affecting multirestrictions.

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

How reproducible:
-

Steps to Reproduce:
1. create fact pattern similar to Person( age == 10 || > 20 )
2. reopen the rule


Actual results:
Operator select box is reset.

Expected results:
GRE should reopen the rule as it was saved.

Additional info:
Affects all kinds of operators (==, <, <==, etc.), contains, excludes, matches soundslike, ...

Comment 1 Edson Tirelli 2013-10-01 13:44:44 UTC
The restriction syntax is deprecated and we definitively don't want to support that in the UI. 

If we are having problems importing existing DRLs that use that syntax, we can use the expression rewrite we have in core to properly convert the deprecated syntax into the extended syntax.

I don't remember if in 5 we supported such syntax, but if we did, it would be good to consider disabling it in 6. This restriction syntax causes clashes with free form expressions that are much more flexible and the best syntax forward.

Comment 2 manstis 2013-10-24 15:00:07 UTC
Edson, "If we are having problems importing existing DRLs that use that syntax, we can use the expression rewrite we have in core to properly convert the deprecated syntax into the extended syntax." Could you please point me to what/where this is? Thanks, Mike

Comment 3 Toni Rikkola 2013-12-03 08:25:34 UTC
Can't reproduce anymore. I could yesterday.

Must have been fixed as a side effect for some other change. Unfortunately I can't figure out what.

Comment 4 Toni Rikkola 2013-12-03 08:36:35 UTC
More details.

The editor no longer saves rules like this:
Person( age == 10 || > 20 )

It does this:
Person( age == 10 || age == > 20 )

Comment 5 Jiri Locker 2014-01-15 08:38:53 UTC
(In reply to Toni Rikkola from comment #4)
> More details.
> 
> The editor no longer saves rules like this:
> Person( age == 10 || > 20 )
> 
> It does this:
> Person( age == 10 || age == > 20 )

Not true for ER7. The rule is still saved as:
Applicant( name == "a"  || == "b" )

Moreover, such rule now cannot be reopened at all. I get an error dialog with message "Unable to complete your request. The following exception occurred: null.". No stack trace in server log.

Comment 6 Toni Rikkola 2014-03-10 13:12:37 UTC
Ok. I found the button next to the constraint that still allowed me to do Person( age == 10 || > 20 ).

I removed the button. Since if the button is used and the rule is saved and reopened the rule will open looking different. The constraints are split into their own lines.
Looking like this:
Person( 
  age == 10 
|| 
  age > 20 )

master:
https://github.com/droolsjbpm/drools-wb/commit/c3fc6286f
6.0.x:
https://github.com/droolsjbpm/drools-wb/commit/4ad8f1b92

Comment 7 Jiri Locker 2014-05-06 14:23:41 UTC
The button allowing to add "more options" to a field was removed and now it is not possible to create multirestrictions using the joint operators (&& !=, || <, etc.).

However rules using this syntax may have been created in product versions 6.0.0 and 6.0.1 or imported from 5.x repositories. These rules will be still displayed incorrectly when open in Guided Rule editor. Optimal solution would be to automatically convert this syntax to the new replacement when the rule is opened...


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