[JBoss JIRA] (WFWIP-255) Existing PVC can slip into as the storage for operator
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-255?page=com.atlassian.jira.plugin.... ]
Petr Kremensky updated WFWIP-255:
---------------------------------
Description:
PVC created manually (any accessModes) by user can be slip into the Operator.
*Things to notice here:*
* WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
* {{foo: bar}} should never pass the validation as it is not a valid storage configuration
*reproduce*
* create PVC, use the ${OPERATOR_NAME}-volume-${OPERATOR_NAME}-0 name - the PVC would be in normal circumstances created by the operator
{noformat}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
{noformat}
* deploy the project
{noformat}
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
spec:
applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
replicas: 1
storage:
foo: bar
{noformat}
The PVC created by user is reused by operator.
Additional details:
* oc get pvc quickstart-volume-quickstart-0 -o yaml
{noformat}
$ oc get pvc quickstart-volume-quickstart-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
...
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
status:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 10Gi
phase: Bound
{noformat}
* oc get wildflyserver quickstart -o yaml
{noformat}
$ oc get wildflyserver quickstart -o yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
...
spec:
applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
replicas: 1
storage:
foo: bar
status:
hosts:
- quickstart-route-statefulset.apps-crc.testing
pods:
- name: quickstart-0
podIP: 10.128.1.101
state: ACTIVE
replicas: 1
scalingdownPods: 0
{noformat}
* oc get pod/quickstart-0 -o yaml
{noformat}
$ oc get pod/quickstart-0 -o yaml
...
volumeMounts:
- mountPath: /wildfly/standalone/data
name: quickstart-volume
...
volumes:
- name: quickstart-volume
persistentVolumeClaim:
claimName: quickstart-volume-quickstart-0
{noformat}
was:
PVC created manually (any accessModes) by user can be slip into the Operator.
*Things to notice here:*
* WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
* {{foo: bar}} should never pass the validation as it is not a valid storage configuration
*reproduce*
* create PVC, use the ${APP_NAME}-volume-quickstart-0 name - the PVC would be in normal circumstances created by the operator
{noformat}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
{noformat}
* deploy the project
{noformat}
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
spec:
applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
replicas: 1
storage:
foo: bar
{noformat}
The PVC created by user is reused by operator.
Additional details:
* oc get pvc quickstart-volume-quickstart-0 -o yaml
{noformat}
$ oc get pvc quickstart-volume-quickstart-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
...
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
status:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 10Gi
phase: Bound
{noformat}
* oc get wildflyserver quickstart -o yaml
{noformat}
$ oc get wildflyserver quickstart -o yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
...
spec:
applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
replicas: 1
storage:
foo: bar
status:
hosts:
- quickstart-route-statefulset.apps-crc.testing
pods:
- name: quickstart-0
podIP: 10.128.1.101
state: ACTIVE
replicas: 1
scalingdownPods: 0
{noformat}
* oc get pod/quickstart-0 -o yaml
{noformat}
$ oc get pod/quickstart-0 -o yaml
...
volumeMounts:
- mountPath: /wildfly/standalone/data
name: quickstart-volume
...
volumes:
- name: quickstart-volume
persistentVolumeClaim:
claimName: quickstart-volume-quickstart-0
{noformat}
> Existing PVC can slip into as the storage for operator
> ------------------------------------------------------
>
> Key: WFWIP-255
> URL: https://issues.jboss.org/browse/WFWIP-255
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Major
>
> PVC created manually (any accessModes) by user can be slip into the Operator.
> *Things to notice here:*
> * WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
> * {{foo: bar}} should never pass the validation as it is not a valid storage configuration
> *reproduce*
> * create PVC, use the ${OPERATOR_NAME}-volume-${OPERATOR_NAME}-0 name - the PVC would be in normal circumstances created by the operator
> {noformat}
> apiVersion: v1
> kind: PersistentVolumeClaim
> metadata:
> name: quickstart-volume-quickstart-0
> spec:
> accessModes:
> - ReadWriteOnce
> - ReadOnlyMany
> - ReadWriteMany
> resources:
> requests:
> storage: 1Mi
> volumeMode: Filesystem
> volumeName: pv0022
> {noformat}
> * deploy the project
> {noformat}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: quickstart
> spec:
> applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
> replicas: 1
> storage:
> foo: bar
> {noformat}
> The PVC created by user is reused by operator.
> Additional details:
> * oc get pvc quickstart-volume-quickstart-0 -o yaml
> {noformat}
> $ oc get pvc quickstart-volume-quickstart-0 -o yaml
> apiVersion: v1
> kind: PersistentVolumeClaim
> metadata:
> name: quickstart-volume-quickstart-0
> ...
> spec:
> accessModes:
> - ReadWriteOnce
> - ReadOnlyMany
> - ReadWriteMany
> resources:
> requests:
> storage: 1Mi
> volumeMode: Filesystem
> volumeName: pv0022
> status:
> accessModes:
> - ReadWriteOnce
> - ReadWriteMany
> - ReadOnlyMany
> capacity:
> storage: 10Gi
> phase: Bound
> {noformat}
> * oc get wildflyserver quickstart -o yaml
> {noformat}
> $ oc get wildflyserver quickstart -o yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: quickstart
> ...
> spec:
> applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
> replicas: 1
> storage:
> foo: bar
> status:
> hosts:
> - quickstart-route-statefulset.apps-crc.testing
> pods:
> - name: quickstart-0
> podIP: 10.128.1.101
> state: ACTIVE
> replicas: 1
> scalingdownPods: 0
> {noformat}
> * oc get pod/quickstart-0 -o yaml
> {noformat}
> $ oc get pod/quickstart-0 -o yaml
> ...
> volumeMounts:
> - mountPath: /wildfly/standalone/data
> name: quickstart-volume
> ...
> volumes:
> - name: quickstart-volume
> persistentVolumeClaim:
> claimName: quickstart-volume-quickstart-0
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-254) Changes in volumeClaimTemplate triggers creation of a new statefulset
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-254?page=com.atlassian.jira.plugin.... ]
Petr Kremensky closed WFWIP-254.
--------------------------------
Resolution: Explained
> Changes in volumeClaimTemplate triggers creation of a new statefulset
> ---------------------------------------------------------------------
>
> Key: WFWIP-254
> URL: https://issues.jboss.org/browse/WFWIP-254
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Critical
> Labels: operator
>
> Adding a volumeClaimTemplate, or existing an existing one leads to the re-creation of statefulset -> all pods are immediately terminated and route is unavailable until some of the pods is ready again.
> *reproduce*
> * deploy operator {noformat}./build/run-openshift.sh{noformat}
> * deploy updatedquickstart project from operator repository {noformat}cat deploy/crds/quickstart-cr.yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: quickstart
> spec:
> applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
> replicas: 2
> storage:
> volumeClaimTemplate:
> spec:
> resources:
> requests:
> storage: 1Mi
> oc apply -f deploy/crds/quickstart-cr.yaml{noformat}
> * wait for both replicas to be ready & print ss creation timestamp & verify application readiness {noformat}oc get pods
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Running 0 2m48s
> quickstart-1 1/1 Running 0 2m48s
> wildfly-operator-54455dbcd8-flnd4 1/1 Running 0 69m
> oc get statefulset.apps/quickstart --template={{.metadata.creationTimestamp}}
> 2019-10-17T13:55:03Z
> curl quickstart-route-wildfly.apps-crc.testing
> {"ip":"10.128.1.36"}
> {noformat}
> * edit the storage field (e.g. storage: 1Mi -> storage: 2Mi)
> * notice the both pods are terminating, stateful set creation timestamp has changed and application route is not available until one of the pods will start again (could take a minute){noformat}oc get pods
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Terminating 0 5m42s
> quickstart-1 1/1 Terminating 0 5m42s
> wildfly-operator-54455dbcd8-flnd4 1/1 Running 0 72m
> oc get statefulset.apps/quickstart --template={{.metadata.creationTimestamp}}
> 2019-10-17T14:00:44Z
> curl quickstart-route-wildfly.apps-crc.testing
> ...
> Application is not available
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-254) Changes in volumeClaimTemplate triggers creation of a new statefulset
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-254?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-254:
--------------------------------------
[~jmesnil] got it, thanks for explanation, I'll close this one, however while playing with the volumes, I run into another one https://issues.jboss.org/browse/WFWIP-255 please take a look once you have a moment. Thanks!
> Changes in volumeClaimTemplate triggers creation of a new statefulset
> ---------------------------------------------------------------------
>
> Key: WFWIP-254
> URL: https://issues.jboss.org/browse/WFWIP-254
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Critical
> Labels: operator
>
> Adding a volumeClaimTemplate, or existing an existing one leads to the re-creation of statefulset -> all pods are immediately terminated and route is unavailable until some of the pods is ready again.
> *reproduce*
> * deploy operator {noformat}./build/run-openshift.sh{noformat}
> * deploy updatedquickstart project from operator repository {noformat}cat deploy/crds/quickstart-cr.yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: quickstart
> spec:
> applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
> replicas: 2
> storage:
> volumeClaimTemplate:
> spec:
> resources:
> requests:
> storage: 1Mi
> oc apply -f deploy/crds/quickstart-cr.yaml{noformat}
> * wait for both replicas to be ready & print ss creation timestamp & verify application readiness {noformat}oc get pods
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Running 0 2m48s
> quickstart-1 1/1 Running 0 2m48s
> wildfly-operator-54455dbcd8-flnd4 1/1 Running 0 69m
> oc get statefulset.apps/quickstart --template={{.metadata.creationTimestamp}}
> 2019-10-17T13:55:03Z
> curl quickstart-route-wildfly.apps-crc.testing
> {"ip":"10.128.1.36"}
> {noformat}
> * edit the storage field (e.g. storage: 1Mi -> storage: 2Mi)
> * notice the both pods are terminating, stateful set creation timestamp has changed and application route is not available until one of the pods will start again (could take a minute){noformat}oc get pods
> NAME READY STATUS RESTARTS AGE
> quickstart-0 1/1 Terminating 0 5m42s
> quickstart-1 1/1 Terminating 0 5m42s
> wildfly-operator-54455dbcd8-flnd4 1/1 Running 0 72m
> oc get statefulset.apps/quickstart --template={{.metadata.creationTimestamp}}
> 2019-10-17T14:00:44Z
> curl quickstart-route-wildfly.apps-crc.testing
> ...
> Application is not available
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-255) Existing PVC can slip into as the storage for operator
by Petr Kremensky (Jira)
Petr Kremensky created WFWIP-255:
------------------------------------
Summary: Existing PVC can slip into as the storage for operator
Key: WFWIP-255
URL: https://issues.jboss.org/browse/WFWIP-255
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Petr Kremensky
Assignee: Jeff Mesnil
PVC created manually (any accessModes) by user can be slip into the Operator.
*Things to notice here:*
* WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
* {{foo: bar}} should never pass the validation as it is not a valid storage configuration
*reproduce*
* create PVC, use the ${APP_NAME}-volume-quickstart-0 name - the PVC would be in normal circumstances created by the operator
{noformat}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
{noformat}
* deploy the project
{noformat}
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
spec:
applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
replicas: 1
storage:
foo: bar
{noformat}
The PVC created by user is reused by operator.
Additional details:
* oc get pvc quickstart-volume-quickstart-0 -o yaml
{noformat}
$ oc get pvc quickstart-volume-quickstart-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
...
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
status:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 10Gi
phase: Bound
{noformat}
* oc get wildflyserver quickstart -o yaml
{noformat}
$ oc get wildflyserver quickstart -o yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
...
spec:
applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
replicas: 1
storage:
foo: bar
status:
hosts:
- quickstart-route-statefulset.apps-crc.testing
pods:
- name: quickstart-0
podIP: 10.128.1.101
state: ACTIVE
replicas: 1
scalingdownPods: 0
{noformat}
* oc get pod/quickstart-0 -o yaml
{noformat}
$ oc get pod/quickstart-0 -o yaml
...
volumeMounts:
- mountPath: /wildfly/standalone/data
name: quickstart-volume
...
volumes:
- name: quickstart-volume
persistentVolumeClaim:
claimName: quickstart-volume-quickstart-0
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12669) Clustering: scattered cache sampling errors
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12669?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-12669:
-------------------------------------
The behavior difference is a result of changes to the behavior of HttpSession.setAttribute(...) for SESSION granularity:
https://github.com/wildfly/wildfly/blob/17.0.x/clustering/web/cache/src/m...
https://github.com/wildfly/wildfly/blob/18.0.x/clustering/web/cache/src/m...
WF17 performs a cache write of all session attributes every call to setAttribute(...) whereas WF18 only performs the cache write at the end of the request. A request received by another node the arrives before the node completes this write will be dirty, since the cache is non-tx. However, in practice, non-tx caches are more appropriately used with ATTRIBUTE granularity. SESSION granularity with a non-tx cache is not a common use case.
> Clustering: scattered cache sampling errors
> -------------------------------------------
>
> Key: WFLY-12669
> URL: https://issues.jboss.org/browse/WFLY-12669
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: clusterbench-ee8.ear
>
>
> The issue is about scattered cache replication across cluster nodes;
> WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following {{cli}} script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
> {noformat}
> The test is run with [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...];
> The same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a *sampling error*;
> Using MOD_JK as load balancer, we have a *22.46%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> Using HAPROXY as load balancer, we have a *1.71%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> Using MOD_CLUSTER as load balancer, we have a *1.85%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> On the server we deploy, as usual, {{clusterbench}} (see attachment clusterbench-ee8.ear).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (ELY-1895) SyslogAuditEndpointTest Failing on later Kernel version
by Darran Lofthouse (Jira)
Darran Lofthouse created ELY-1895:
-------------------------------------
Summary: SyslogAuditEndpointTest Failing on later Kernel version
Key: ELY-1895
URL: https://issues.jboss.org/browse/ELY-1895
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Affects Versions: 1.11.0.CR1, 1.10.2.Final
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.10.4.CR1, 1.11.0.CR2
This test is based on using a bad address for UDP to trigger a failure "0.35.98.76", however with the later Kernel version this error no longer occurs.
Overall I believe safer to develop a more reliable failure scenario for this test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4484) [DMN Designer] Data Types - Refactor the Data Types list to use a drag and drop mechanism
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4484?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4484:
--------------------------------
Attachment: issue6-drag-used-type.webm
> [DMN Designer] Data Types - Refactor the Data Types list to use a drag and drop mechanism
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-4484
> URL: https://issues.jboss.org/browse/DROOLS-4484
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: issue1-drag-edit.webm, issue3-click-hide.webm, issue5-reorder-structure.webm, issue6-drag-used-type.webm, s1.gif, s2.gif, s3.gif, s4.gif, s5.gif
>
>
> This JIRAs covers all refactoring to apply the drag and drop mechanism (https://issues.jboss.org/browse/DROOLS-4483) into the DMN Data Types list.
> *Acceptance criteria:*
> - The drag and drop feature must behaves as the following scenarios describe:
> -- *Scenario 1:* When users drag tCompany up and it's collapsed, all fields are dragged with tCompany:
> !s1.gif|width=400!
> -- *Scenario 2:* When users drag tCompany up and it's not collapsed, all fields are dragged with tCompany:
> !s2.gif|width=400!
> -- *Scenario 3:* When users drag name below of a structured data type (address), the name field is moved as a nested data type:
> !s3.gif|width=400!
> -- *Scenario 4:* When users drag a new field into the collapsed tCompany, it automatically expands and the new field is added to it:
> !s4.gif|width=400!
> -- *Scenario 5:* When users drag a data type above or below of another one, the position is persisted in the model:
> !s5.gif|width=400!
> - The keyboard control can not be affected
> -- User need to be able start edit mode
> -- User need to be able finish/cancel edit mode
> - Search can not be affected
> - Imported data types are not editable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4484) [DMN Designer] Data Types - Refactor the Data Types list to use a drag and drop mechanism
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4484?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4484:
--------------------------------
Attachment: issue5-reorder-structure.webm
> [DMN Designer] Data Types - Refactor the Data Types list to use a drag and drop mechanism
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-4484
> URL: https://issues.jboss.org/browse/DROOLS-4484
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: issue1-drag-edit.webm, issue3-click-hide.webm, issue5-reorder-structure.webm, s1.gif, s2.gif, s3.gif, s4.gif, s5.gif
>
>
> This JIRAs covers all refactoring to apply the drag and drop mechanism (https://issues.jboss.org/browse/DROOLS-4483) into the DMN Data Types list.
> *Acceptance criteria:*
> - The drag and drop feature must behaves as the following scenarios describe:
> -- *Scenario 1:* When users drag tCompany up and it's collapsed, all fields are dragged with tCompany:
> !s1.gif|width=400!
> -- *Scenario 2:* When users drag tCompany up and it's not collapsed, all fields are dragged with tCompany:
> !s2.gif|width=400!
> -- *Scenario 3:* When users drag name below of a structured data type (address), the name field is moved as a nested data type:
> !s3.gif|width=400!
> -- *Scenario 4:* When users drag a new field into the collapsed tCompany, it automatically expands and the new field is added to it:
> !s4.gif|width=400!
> -- *Scenario 5:* When users drag a data type above or below of another one, the position is persisted in the model:
> !s5.gif|width=400!
> - The keyboard control can not be affected
> -- User need to be able start edit mode
> -- User need to be able finish/cancel edit mode
> - Search can not be affected
> - Imported data types are not editable
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months