September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3022) [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name

by Guilherme Carreiro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-3022?page=com.atlassian.jira.plugi... ] Guilherme Carreiro updated DROOLS-3022: --------------------------------------- Description: The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. --- Prototype: !validation.png|thumbnail! was: The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. > [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name > ------------------------------------------------------------------------------------- > > Key: DROOLS-3022 > URL: https://issues.jboss.org/browse/DROOLS-3022 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Labels: drools-tools > Attachments: validation.png > > > The Data Type name must be unique at the level that it's defined; e.g. > - tPerson > -- uuid > -- name > -- city (Structure) > --- uuid > --- name > The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. > --- > Prototype: !validation.png|thumbnail! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3022) [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name

by Guilherme Carreiro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-3022?page=com.atlassian.jira.plugi... ] Guilherme Carreiro updated DROOLS-3022: --------------------------------------- Description: The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. --- Prototype: !validation.png|thumbnail! was: The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. --- Prototype: !validation.png|thumbnail! > [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name > ------------------------------------------------------------------------------------- > > Key: DROOLS-3022 > URL: https://issues.jboss.org/browse/DROOLS-3022 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Labels: drools-tools > Attachments: validation.png > > > The Data Type name must be unique at the level that it's defined; e.g. > - tPerson > -- uuid > -- name > -- city (Structure) > --- uuid > --- name > The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. > --- > Prototype: > !validation.png|thumbnail! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3022) [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name

by Guilherme Carreiro (JIRA)

Guilherme Carreiro created DROOLS-3022: ------------------------------------------ Summary: [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name Key: DROOLS-3022 URL: https://issues.jboss.org/browse/DROOLS-3022 Project: Drools Issue Type: Task Components: DMN Editor Reporter: Guilherme Carreiro Assignee: Guilherme Carreiro The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3022) [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name

by Guilherme Carreiro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-3022?page=com.atlassian.jira.plugi... ] Guilherme Carreiro updated DROOLS-3022: --------------------------------------- Description: The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. was: The Data Type name must be unique at the level that it's defined; e.g. - tPerson -- uuid -- name -- city (Structure) --- uuid --- name The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. > [DMN Designer] Data Types - Validations - Validate the uniqueness of a Data Type name > ------------------------------------------------------------------------------------- > > Key: DROOLS-3022 > URL: https://issues.jboss.org/browse/DROOLS-3022 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Labels: drools-tools > > The Data Type name must be unique at the level that it's defined; e.g. > - tPerson > -- uuid > -- name > -- city (Structure) > --- uuid > --- name > The Data Type above is valid, because _tPerson.uuid_ and _tPerson.city.uuid_ are in different levels. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2293: -------------------------------- So A (coord) writes to B, asking it to leave A. At the same time, B writes to A (for B, A is still the coord), asking it to remove B from the view. I'll have to see if this needs to be handled explicitly, or whether we should simply let failure detection do its job... > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.15 > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-435) Fix failing UI automation tests

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-435: ------------------------------------ Summary: Fix failing UI automation tests Key: SWSQE-435 URL: https://issues.jboss.org/browse/SWSQE-435 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/python-ui-tests-... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2293 at 9/24/18 9:09 AM: --------------------------------------------------------- Reducing the timeout on FD_ALL helps: {{new FD_ALL().timeout(3000).interval(1000)}}. I have to investigate whether this is a bug or not, as the first and second in line leaving at the same time is something that will probably have to solved by failure detection. I'll look into this this week. was (Author: belaban): Reducing the timeout on FD_ALL helps: {{ new FD_ALL().timeout(3000).interval(1000)}}. I have to investigate whether this is a bug or not, as the first and second in line leaving at the same time is something that will probably have to solved by failure detection. I'll look into this this week. > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.15 > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-431) Add Workoads Tabs automation for Service details

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-431?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan resolved SWSQE-431. ---------------------------------- Resolution: Done https://github.com/Kiali-QE/kiali-qe-python/pull/78 > Add Workoads Tabs automation for Service details > ------------------------------------------------ > > Key: SWSQE-431 > URL: https://issues.jboss.org/browse/SWSQE-431 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2293) Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2293?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2293: -------------------------------- Reducing the timeout on FD_ALL helps: {{ new FD_ALL().timeout(3000).interval(1000)}}. I have to investigate whether this is a bug or not, as the first and second in line leaving at the same time is something that will probably have to solved by failure detection. I'll look into this this week. > Graceful concurrent leaving of coordinator(s) leaves the cluster with stale views > --------------------------------------------------------------------------------- > > Key: JGRP-2293 > URL: https://issues.jboss.org/browse/JGRP-2293 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.15 > > > JGroups does not handle concurrent leaving of nodes correctly. This is a typical use case in cloud environment when scaled down with an autoscaler/manually which we need to handle. > A simple test can be devised which fails first n (where n>1) nodes from a cluster, reproducer PR https://github.com/belaban/JGroups/pull/397 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3021) [DMN Designer] Data Types - Constraints - Enumeration option component

by Guilherme Carreiro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-3021?page=com.atlassian.jira.plugi... ] Guilherme Carreiro updated DROOLS-3021: --------------------------------------- Story Points: 8 (was: 5) > [DMN Designer] Data Types - Constraints - Enumeration option component > ---------------------------------------------------------------------- > > Key: DROOLS-3021 > URL: https://issues.jboss.org/browse/DROOLS-3021 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Labels: drools-tools > Attachments: enumaration-component.png > > > - When "Enumeration" is selected in the _Base Component_, the _Enumeration component_ must be loaded; > - The _Enumeration component_ is an input that creates "tags" when the user presses "Enter", the UI component must look like this: > !enumaration-component.png|thumbnail! > - The field (for creating a tag), must show the appropriated widget for each type of data (Number, Day/Time Duration, Year/Mos Duration, Date/Time, Date, Time); > - When the user clicks in a tag, it must be removed. > - When the user clicks in the Data Type "Save" button, the values (tags) must be persisted in the Data Type. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2018