Bug 998922

Summary: [guided editor] 'From accumulate' pattern editor does not offer Number
Product: [Retired] JBoss BRMS Platform 6 Reporter: Jiri Locker <jlocker>
Component: Business CentralAssignee: Toni Rikkola <trikkola>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Locker <jlocker>
Severity: low Docs Contact:
Priority: high    
Version: 6.0.0CC: etirelli
Target Milestone: ER6   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 853993 Environment:
Last Closed: 2014-08-06 20:19:02 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 853993    
Bug Blocks:    

Description Jiri Locker 2013-08-20 10:59:55 UTC
+++ This bug was initially created as a clone of Bug #853993 +++

Description of problem:
When building 'From accumulate' conditional element the result of the accumulation is usually Number, however the pattern editor for the accumulation result only offers imported types.

Of course Number could be explicitely imported, but importing from java.lang package is redundant. Moreover there is inconsistency with pattern editor for 'From collect' which offers List, Set and Collection (java.util) although they are not imported

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


How reproducible:


Steps to Reproduce:
1. in Guided editor, add 'From Accumulate' condition
2. click 'click to add pattern...' *above* the 'From Accumulate' keywords
  
Actual results:
Number type is missing in the selection list

Expected results:
Number should be offered

Additional info:
Having Number available is very handy and it used to work in Guvnor 5.1.

--- Additional comment from Jiri Locker on 2012-09-03 16:02:45 CEST ---

Might be related to this change https://issues.jboss.org/browse/GUVNOR-1367.

Comment 1 Edson Tirelli 2013-10-01 00:33:40 UTC
Can we automatically import classes from java.lang? Or some similar solution?

Comment 5 Toni Rikkola 2013-10-17 21:06:20 UTC
Well I tried to just hard code Number in, but turns out this is not that simple with the current Data Model Oracle in the background. Also it feels hacky.

The plan has been to let the users control what the dropdowns contain. This is why the "Import Suggestions" are not actual imports for the project. What the "Import suggestions" should do in my mind is:
* Add everything listed in them show in the fact lists. 
* When the user selects a fact from a dropdown, import it and add the fact to the file's import list.
This way the admin could just add the java.lang classes to the "Import Suggestions" once and this would fix both this ticket and make using the workbench more user friendly. Adding automatic addition to fact selectors takes a while. Since our fact selectors are not unified and all over the place.

Since both solutions take time. We do not have much time. Both solutions can cause more bugs. And there is a workaround, I would get this done properly for community 6.1 release and if we have time, for the final product release.

Comment 6 Edson Tirelli 2013-10-18 02:37:51 UTC
Toni, most of the accumulate functions return numbers. I would like to suggest you give it another thought about this, even if it is to treat Number as a special case for accumulate. 

Lets talk tomorrow on IRC.

Comment 7 Toni Rikkola 2013-11-28 07:33:04 UTC
Ok. I think I found a clean way to do this. 

java.lang.Number is imported by default to each guided rule asset and each project's import suggestion list. This means Number is visible when accumulate, or anything else in the guided rule editor, is used. 

The import is added when a new project or guided rule is created. So it is possible for the user to remove it.

This also supports a feature planned in the future, where we have a list of default imports like List, Map, Integer, Double and so on.

Comment 8 Jiri Locker 2014-01-13 15:33:32 UTC
Fix verified in ER7.