[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Edson Tirelli edited comment on DROOLS-3193 at 10/30/18 10:10 AM:
------------------------------------------------------------------
Liz, no, the labels are arbitrary. We should not "number" instances.
For instance, pretend I am creating a scenario that involves a sale of goods between two companies. I can label one company "seller" and the other company "buyer".
|| seller : Company | buyer: Company ||
|| ... | ... ||
was (Author: tirelli):
Liz, no, the labels are arbitrary. We should not "number" instances.
For instance, pretent I am creating a scenario that involves a sale of goods between two companies. I can label one company "seller" and the other company "buyer".
|| seller : Company | buyer: Company ||
|| ... | ... ||
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Edson Tirelli (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-3193:
---------------------------------------
Liz, no, the labels are arbitrary. We should not "number" instances.
For instance, pretent I am creating a scenario that involves a sale of goods between two companies. I can label one company "seller" and the other company "buyer".
|| seller : Company | buyer: Company ||
|| ... | ... ||
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3193:
-------------------------------------
[~kkufova][~tirelli] Should data object instances be ID'd in the table by column position or instance number (2nd instance of x, or 2nd column position?)
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3202) [DMN Designer] Data Type dialog - Validation - Data Type name cannot be a built in Data Type
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3202?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3202:
--------------------------------
Description:
The Data Type dialog cannot allow the following data type names:
- number
- string
- boolean
- days and time duration
- years and months duration
- time
- date and time
- any
- date
- context
A validation (error) message should be shown to the user alerting that the operation mentioned above is not allowed.
h2. Acceptance test
- Creation of a new data type (/)
- Editing an existing data type (/)
was:
The Data Type dialog cannot allow the following data type names:
- number
- string
- boolean
- days and time duration
- years and months duration
- time
- date and time
- any
- date
- context
A validation (error) message should be shown to the user alerting that the operation mentioned above is not allowed.
h2. Acceptance test
- Creation of a new (/)
- Editing an existing
> [DMN Designer] Data Type dialog - Validation - Data Type name cannot be a built in Data Type
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-3202
> URL: https://issues.jboss.org/browse/DROOLS-3202
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: drools-tools
>
> The Data Type dialog cannot allow the following data type names:
> - number
> - string
> - boolean
> - days and time duration
> - years and months duration
> - time
> - date and time
> - any
> - date
> - context
> A validation (error) message should be shown to the user alerting that the operation mentioned above is not allowed.
> h2. Acceptance test
> - Creation of a new data type (/)
> - Editing an existing data type (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3202) [DMN Designer] Data Type dialog - Validation - Data Type name cannot be a built in Data Type
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3202?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3202:
--------------------------------
Description:
The Data Type dialog cannot allow the following data type names:
- number
- string
- boolean
- days and time duration
- years and months duration
- time
- date and time
- any
- date
- context
A validation (error) message should be shown to the user alerting that the operation mentioned above is not allowed.
h2. Acceptance test
- Creation of a new (/)
- Editing an existing
was:
The Data Type dialog cannot allow the following data type names:
- number
- string
- boolean
- days and time duration
- years and months duration
- time
- date and time
- any
- date
- context
A validation (error) message should be shown to the user alerting that the operation mentioned above is not allowed.
h2. Acceptance test
- Creation of a new
- Editing an existing
> [DMN Designer] Data Type dialog - Validation - Data Type name cannot be a built in Data Type
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-3202
> URL: https://issues.jboss.org/browse/DROOLS-3202
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: drools-tools
>
> The Data Type dialog cannot allow the following data type names:
> - number
> - string
> - boolean
> - days and time duration
> - years and months duration
> - time
> - date and time
> - any
> - date
> - context
> A validation (error) message should be shown to the user alerting that the operation mentioned above is not allowed.
> h2. Acceptance test
> - Creation of a new (/)
> - Editing an existing
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3207) [DMN Designer] Cell/header selection improvements
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3207?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3207:
-----------------------------------
Tester: Jozef Marko
Labels: drools-tools (was: )
> [DMN Designer] Cell/header selection improvements
> -------------------------------------------------
>
> Key: DROOLS-3207
> URL: https://issues.jboss.org/browse/DROOLS-3207
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.13.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Headers and cells can now be selected however there is some inconsistency to their behaviour.
> It is possible to select a header cell first and then a body cell with {{ctrl}} pressed and both remain selected. If however you select first a body cell and then a header cell with {{ctrl}} pressed the body cell becomes deselected (this is because {{HeaderSingleCellSelectionStrategy}} clears the models selections).
> Also, following changes for "drill down" {{LiteralExpressionGrid}} and {{UndefinedExpressionGrid}} "act on their own" regarding selection. i.e. create a {{Context}} and add a new {{ContextEntry}} setting its {{Expression}} to a {{LiteralExpression}}. Select multiple cells with {{ctrl}} and when the {{LiteralExpressionGrid}} and {{UndefindExpressionGrid}} cells' are selected the {{Context}} cells become deselected. Ideally the parent cell selections should change too so they _appear_ to be visually selected together.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3207) [DMN Designer] Cell/header selection improvements
by Michael Anstis (Jira)
Michael Anstis created DROOLS-3207:
--------------------------------------
Summary: [DMN Designer] Cell/header selection improvements
Key: DROOLS-3207
URL: https://issues.jboss.org/browse/DROOLS-3207
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Affects Versions: 7.13.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
Headers and cells can now be selected however there is some inconsistency to their behaviour.
It is possible to select a header cell first and then a body cell with {{ctrl}} pressed and both remain selected. If however you select first a body cell and then a header cell with {{ctrl}} pressed the body cell becomes deselected (this is because {{HeaderSingleCellSelectionStrategy}} clears the models selections).
Also, following changes for "drill down" {{LiteralExpressionGrid}} and {{UndefinedExpressionGrid}} "act on their own" regarding selection. i.e. create a {{Context}} and add a new {{ContextEntry}} setting its {{Expression}} to a {{LiteralExpression}}. Select multiple cells with {{ctrl}} and when the {{LiteralExpressionGrid}} and {{UndefindExpressionGrid}} cells' are selected the {{Context}} cells become deselected. Ideally the parent cell selections should change too so they _appear_ to be visually selected together.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4190) Distinguish undefined metric value
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4190?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFCORE-4190:
-------------------------------------
When the microprofile-metrics-smallrye extension will register MP metrics from WildFly metrics, it will ignore (and not expose from its HTTP endpoints) any metric that returns an undefined value.
> Distinguish undefined metric value
> ----------------------------------
>
> Key: WFCORE-4190
> URL: https://issues.jboss.org/browse/WFCORE-4190
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
> Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
> When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
> This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
> Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
> When the metric is defined[2], it specifies an undefined metric value of 0.
> From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
> * the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
> * statistics-enabled is true but there is no network traffic on the HTTP listener
> These 2 cases are wildly different but it is not possible to distinguish between them
> In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
> This parameter is taken into account only for metric attribute:
> * if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
> * if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
> This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
> When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
> These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
> [1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
> [2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
> [3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
> [4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4190) Distinguished undefined metric value
by Jeff Mesnil (Jira)
Jeff Mesnil created WFCORE-4190:
-----------------------------------
Summary: Distinguished undefined metric value
Key: WFCORE-4190
URL: https://issues.jboss.org/browse/WFCORE-4190
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 7.0.0.Alpha4
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
When the metric is defined[2], it specifies an undefined metric value of 0.
>From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
* the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
* statistics-enabled is true but there is no network traffic on the HTTP listener
These 2 cases are wildly different but it is not possible to distinguish between them
In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
This parameter is taken into account only for metric attribute:
* if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
* if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
[1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
[2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
[3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
[4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFCORE-4190) Distinguish undefined metric value
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4190?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4190:
--------------------------------
Summary: Distinguish undefined metric value (was: Distinguished undefined metric value)
> Distinguish undefined metric value
> ----------------------------------
>
> Key: WFCORE-4190
> URL: https://issues.jboss.org/browse/WFCORE-4190
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
>
> WildFly resources can registered metrics for runtime read-only attributes whose value change during server activity.
> Some of these metrics are "disabled" by default (as they may be expensive to compute) and are enabled using a boolean attribute named statistics-enabled in their resource tree.
> When these metrics would not be able to compute their value, they could register a "undefined metric value" that would be returned by the :read-attribute handler if the metric read handler would return an undefined value.
> This causes a significant issue when one observes WildFly as it generates metrics figures that gives an incorrect observation of the server activity.
> Typical example is undertow metrics to see bytes sent and received on its http(s)-listeners[1].
> When the metric is defined[2], it specifies an undefined metric value of 0.
> From the outside, when a monitoring tool will fetch value for the bytes-sent metric, it may return 0 in 2 different cases:
> * the metric is not enabled if the statistics-enabled attribute at [3] is false (which is the case by default). This does not mean that there is no network traffic.
> * statistics-enabled is true but there is no network traffic on the HTTP listener
> These 2 cases are wildly different but it is not possible to distinguish between them
> In order to distinguish these 2 cases, the :read-attribute operation (and by extension the :read-resource operation) will be enhanced with a "include-undefined-metric" operation parameter.
> This parameter is taken into account only for metric attribute:
> * if include-undefined-metric is true, the operation will return a undefined value from the metric's read handler *without substituting it by the *undefined metric value* from the metric AttributeDefinition
> * if the flag is false (by default), the current behaviour is used (if the read handler returns an undefined value, uses the *undefined metric value* from the metric AttributeDefinition.
> This will allow external monitoring tool (as well as the metrics subsystem from WFLY-10712) to know that the metric does not return a meaningful value.
> When I looked at various metrics registered in WildFly, some of them returns a meaningless value if the runtime code can not compute the value (e.g. Undertow statistics returns 0 if they are not able to obtain the underlying statistics[4]) in addition to defined an "undefined metric value" from the metric AttributeDefinition.
> These read handlers would have to be fixed so they MUST NOT return a defined value that does not correspond to the actual value required by the operation.
> [1] http://wildscribe.github.io/WildFly/14.0/subsystem/undertow/server/http-l...
> [2] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
> [3] http://wildscribe.github.io/WildFly/14.0//subsystem/undertow/index.html#a...
> [4] https://github.com/wildfly/wildfly/blob/8f620bbe6d481c9c2c6422e2250326a98...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month