[JBoss JIRA] (DROOLS-2911) Update Scenario Simulation command to use the new module
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-2911?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-2911:
---------------------------------
Story Points: 2 (was: 8)
> Update Scenario Simulation command to use the new module
> --------------------------------------------------------
>
> Key: DROOLS-2911
> URL: https://issues.jboss.org/browse/DROOLS-2911
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
>
> Use new kie-wb-common-command-api for Scenario Simulation commands
> *Specs:*
> Preliminary steps:
> * Add dependency to the new module containing AbstractCommand
> * Split CommandExecutor class into two classes: a pure executor and a general event handler that accepts all the events
> * Refactor ScenarioGridMode.bindContent and ScenarioSimulationViewImpl.refreshContent to be able to refresh internal model and grid model in a simple way (for now it refreshes only the errors from the internal model)
> * Refactor remaining actions with no commands (for instance flush of inline editing should fire an event instead of update directly the code). More or less all the methods that work with ScenarioGridModel should be inside a command
> Move to common API:
> * Implement ScenarioCommandManager extending org.kie.workbench.common.command.impl.CommandManagerImpl
> * Refactor all commands to extend org.kie.workbench.common.command.AbstractCommand
> * Implement a default undo strategy that dump the model and restore it when needed (we should consider how to *preserve selections, columns width and right panel status*)
> * Implement ScenarioCommandRegistry extending org.kie.workbench.common.command.registry.command.CommandRegistryImpl
> * Implement ScenarioCommandController (or with a better name :) ) that wrap ScenarioCommandRegistry and ScenarioCommandManager and exposes some API for safe command execute (for instance undo only of the last executed method). This class should be the entry point to manage commands (probably it should be declared as @Dependent and injected into the Presenter)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3000) Design data type constraints UX
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3000:
--------------------------------
Story Points: 5 (was: 3)
> Design data type constraints UX
> --------------------------------
>
> Key: DROOLS-3000
> URL: https://issues.jboss.org/browse/DROOLS-3000
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, Screen Shot 2018-09-28 at 2.44.59 PM.png, date-time.png, date.png, enumration-widget.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3282) Should not move to next AgendaGroup even if current is empty
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3282?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3282:
-----------------------------------
Sprint: 2018 Week 45-47 (was: 2018 Week 45-47, 2018 Week 48-50)
> Should not move to next AgendaGroup even if current is empty
> ------------------------------------------------------------
>
> Key: DROOLS-3282
> URL: https://issues.jboss.org/browse/DROOLS-3282
> Project: Drools
> Issue Type: Bug
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core
>
> Current implementation moves to next agend group if current agenda group is empty. This is unexpected, and in part detrimental in the impl of units: it is not possible to suspend execution of rules by switching to an empty group, because the engine will move to the next group anyway:
> {code}
> return nextRule != null && (!ruleAgendaItem.getAgendaGroup().equals( nextRule.getAgendaGroup() ) || !isHigherSalience(nextRule));
> {code}
> because the change in behavior is potentially backwards incompatible we add a flag {{keepWhenEmpty}} that must be set to {{true}} when we want to enable this new behavior
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3282) Should not move to next AgendaGroup even if current is empty
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3282?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi closed DROOLS-3282.
----------------------------------
Resolution: Rejected
not the right fix, add new primitive for suspension
> Should not move to next AgendaGroup even if current is empty
> ------------------------------------------------------------
>
> Key: DROOLS-3282
> URL: https://issues.jboss.org/browse/DROOLS-3282
> Project: Drools
> Issue Type: Bug
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core
>
> Current implementation moves to next agend group if current agenda group is empty. This is unexpected, and in part detrimental in the impl of units: it is not possible to suspend execution of rules by switching to an empty group, because the engine will move to the next group anyway:
> {code}
> return nextRule != null && (!ruleAgendaItem.getAgendaGroup().equals( nextRule.getAgendaGroup() ) || !isHigherSalience(nextRule));
> {code}
> because the change in behavior is potentially backwards incompatible we add a flag {{keepWhenEmpty}} that must be set to {{true}} when we want to enable this new behavior
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months