opened
gitgabrio
username_0
@username_1 @Rikkola @username_2 
See https://issues.jboss.org/browse/DROOLS-3608

Please check for regression. For the moment being there is not any modification client-side, so editing of nested objects is not possible.
Drools 3608
issue
created
gitgabrio
username_0
jenkins please retest this
comment
created
gitgabrio
username_0
jenkins please retest this
comment
created
kkufova
username_1
comment
created
gitgabrio
username_0
_I'm not sure it should be possible at all to move objects from expected to given (or the other way around) at all; the semantics of DMN is different then RULES: in rules in the RightPanel we see DataType (think of it like java class) and each column created out of them is actually an instance (that's why you can create more then one, wherever you want) while with DMN they are actually "instance" (whatever type) of very specific kind - InputData for the "GIVEN" group and "DecisionData" for the "EXPECTED"); so, moving one object from EXPECTED to GIVEN would mean change its meaning from "decision" to "input", but this should not happen IMO, 'cause it would be a change in the underlying dmn model (that we should not do). @username_2 WDYT?_
comment
created
danielezonca
username_2
@username_0 
It is possible to move a column from `EXPECT` to `GIVEN` because if you want to test a subdecision (so test only partially the model) you should provide all the inputs to that node, even if it is a decision node.
It is useless the opposite (from `GIVEN` to `EXPECT`) but at the moment it is not forbidden
comment
created
gitgabrio
username_0
@username_1 
I am not completely sure that this DMN file should work, but currently it causes an unexpected error when trying to invoke the collection popup from database when it is moved to the GIVEN section:

| Uncaught exception: Index: 0, Size: 0

_This is a client-side issue, related to unsupported top-level collection, and will be addressed in specific ticket (https://issues.jboss.org/browse/DROOLS-3759)_
comment
created
kkufova
username_1
@username_0, I tried the most basic example which seems like it's not working; try [this DMN file](http://file.emea.redhat.com/username_1/dmn-test.dmn) and [this test scenario](http://file.emea.redhat.com/username_1/sc-test.scesim). Both defined test scenarios are failing.
comment
created
gitgabrio
username_0
@username_1 
I imported both the DMN file and the scesim one without error: what is the issue you are seeing?
comment
created
kkufova
username_1
@username_0, the tests are failing but they should be passing instead.
comment
created
gitgabrio
username_0
@username_1 
I've verified with @username_2, and that failure is expected. Top level collection are not yet fully supported (i.e. they do not works, yet). If previously you did not see "failure" launching the run it is only by "chance".
comment
created
kkufova
username_1
@username_0, @username_2, what are you saying? What exactly does this PR introduces then? I don't accept the answer that "top-level collections don't work yet", as they work with some DMNs (and they don't work outside of this PR). I am not sure I'm comfortable with this partial solution, we already reported two issues because of this PR (two I'm aware of) and this looks like a candidate for another one. The DMN I uploaded is the most basic DMN with a list that I can think of. If this does not work, what should work?
comment
created
gitgabrio
username_0
@username_1 @username_2 
I'm going to create an container ticket for the top-level feature and set the existing ones as subtask, to make it clear the scope of every single piece.
This mean that I will close this PR and I will create a new one that will include everything.
comment
created
kkufova
username_1
@username_0, sounds good to me, thanks!
comment