Bug 1012553
| Summary: | GRE doesn't handle multirestrictions when reopening rule | ||
|---|---|---|---|
| Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Jiri Locker <jlocker> |
| Component: | Business Central | Assignee: | Toni Rikkola <trikkola> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jiri Locker <jlocker> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0.0 | CC: | dhoffman, etirelli, mwinkler, trikkola, vigoyal |
| Target Milestone: | ER1 | ||
| Target Release: | 6.0.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
Fixed Issue Summary:
While saving a guided rule with multiple restrictions on a single fact field, users were unable to reopen the rule and were presented with an error message. This issue has been fixed by removing the "more options" button to a field, and now it is not possible to create multiple restrictions using the joint operators (&& !=, || <, etc.).
Cause: Saving a Guided Rule with multiple restrictions on a single fact field.
Consequence: It is not possible to reopen the rule. The user is presented with an error message.
Workaround (if any): None.
Result:
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-08-06 19:53:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jiri Locker
2013-09-26 15:55:25 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. 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 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. More details. The editor no longer saves rules like this: Person( age == 10 || > 20 ) It does this: Person( age == 10 || age == > 20 ) (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. 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 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... |