[JBoss JIRA] (DROOLS-3080) SpreadsheetCompiler generates wrong LHS order
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-3080:
-----------------------------------------
Summary: SpreadsheetCompiler generates wrong LHS order
Key: DROOLS-3080
URL: https://issues.jboss.org/browse/DROOLS-3080
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.12.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
When a Spreadsheet (xls) has CONDITION columns like:
- The first column doesn't have Fact (e.g. accumulate(...))
- The second column has Fact (e.g. $p:Person(...))
(See attached LhsOrder.xls)
, SpreadsheetCompiler generates a DRL with inverse order in LHS.
{noformat}
rule "LhsOrder_11"
when
$p:Person(name == "John", age == $max)
accumulate(Person(name == "John", $a : age); $max:max($a))
then
System.out.println("hello, " + $p.getName());
end
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (AG-94) "Closing connection in incorrect state" log spam
by Stuart Douglas (Jira)
[ https://issues.jboss.org/browse/AG-94?page=com.atlassian.jira.plugin.syst... ]
Stuart Douglas commented on AG-94:
----------------------------------
This is very easy to reproduce if you call io.agroal.pool.ConnectionPool#getConnection twice in the same transaction.
Two different ConnectionWrapper instances will be created, and two different io.agroal.narayana.NarayanaTransactionIntegration.InterposedSynchronization will be registered with the transaction. The first one will close the connection as normal, but the second one will trigger the 'handler not in CHECKED_OUT implies FLUSH' code path. This async flush code can then kill the connection while another transaction is using it.
> "Closing connection in incorrect state" log spam
> ------------------------------------------------
>
> Key: AG-94
> URL: https://issues.jboss.org/browse/AG-94
> Project: Agroal
> Issue Type: Bug
> Components: pool
> Affects Versions: 1.1
> Environment: WildFly 14.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Luis Barreiro
> Priority: Major
>
> My WildFly application gets a lot of log spam like this:
> {code}
> 13:45:39,741 WARN [io.agroal.pool] (Agroal_17017539771) WFLYAG0601: DLS_DS: Closing connection in incorrect state CHECKED_IN
> {code}
> In trying to debug it, I found a potential cause. ConnectionPool line 251 comments that "handler not in CHECKED_OUT implies FLUSH" but that appears to be a bad assumption. For the stack trace below (obtained by setting a breakpoint at ConnectionPool line 346), the state was CHECKED_IN.
> I also filed WFLY-11037, but nobody has looked at it and this seems more like an Agroal bug at this point.
> {code}
> "default task-2" #149 prio=5 os_prio=0 tid=0x000000002315c800 nid=0x10498 at breakpoint[0x0000000035c5b000]
> java.lang.Thread.State: RUNNABLE
> at io.agroal.pool.ConnectionPool$FlushTask.<init>(ConnectionPool.java:346)
> at io.agroal.pool.ConnectionPool.returnConnection(ConnectionPool.java:252)
> at io.agroal.pool.ConnectionHandler.returnConnection(ConnectionHandler.java:68)
> at io.agroal.pool.wrapper.ConnectionWrapper.close(ConnectionWrapper.java:186)
> at io.agroal.narayana.NarayanaTransactionIntegration$InterposedSynchronization.afterCompletion(NarayanaTransactionIntegration.java:127)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization$$Lambda$711/1634329013.accept(Unknown Source)
> at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:223)
> at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.afterCompletion(AbstractTransaction.java:306)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> - locked <0x00000000f6201298> (a java.lang.Object)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:232)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:178)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept(TransactionalInterceptorRequired.java:53)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept(TransactionalInterceptorBase.java:88)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:47)
> at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> at com.sg.song.dls.config.unified.UnifiedConfig$Proxy$_$$_WeldSubclass.changeConfigValues(Unknown Source)
> at com.sg.song.dls.config.unified.UnifiedConfig$Proxy$_$$_WeldClientProxy.changeConfigValues(Unknown Source)
> at com.sg.song.dls.rest.ui.config.UIUnifiedConfigService.changeSettings(UIUnifiedConfigService.java:45)
> at com.sg.song.dls.rest.ui.config.UIUnifiedConfigService$Proxy$_$$_WeldClientProxy.changeSettings(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.ResourceMethodInvoker$$Lambda$765/920149366.get(Unknown Source)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> - locked <0x00000000f61fac30> (a org.jboss.resteasy.core.interception.PostMatchContainerRequestContext)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
> at org.jboss.resteasy.core.SynchronousDispatcher$$Lambda$763/354670022.run(Unknown Source)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
> at org.jboss.resteasy.core.SynchronousDispatcher$$Lambda$764/1839877196.get(Unknown Source)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> - locked <0x00000000f61f9880> (a org.jboss.resteasy.core.interception.PreMatchContainerRequestContext)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$677/604722672.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$678/2109666898.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFLY-11119) message-clustering cli config failing
by Jean-Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFLY-11119?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise closed WFLY-11119.
---------------------------------------
Resolution: Rejected
Not a bug, this is JBEAP quickstarts used with wildfly.
> message-clustering cli config failing
> -------------------------------------
>
> Key: WFLY-11119
> URL: https://issues.jboss.org/browse/WFLY-11119
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Reporter: Jean-Francois Denise
> Assignee: Eduardo Martins
> Priority: Major
>
> Also applies to message-clustering-singleton
> Seems that the full-ha has now CONSOLE enabled.
> I am using JBEAP quickstarts and wildfly 15.0.0.Alpha1-SNAPSHOT
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-1
> Operation: /subsystem=logging/console-handler=CONSOLE:add(level=INFO,formatter="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n")
> Failure: WFLYCTL0212: Duplicate resource [
> ("subsystem" => "logging"),
> ("console-handler" => "CONSOLE")
> ]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (WFCORE-4153) Capability 'org.wildfly.nosql.mongo.driver-service' is unknown error thrown on WildFly 14 + current master branch
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFCORE-4153?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFCORE-4153:
--------------------------------------
[~brian.stansberry] it didn't help, comment with more details added to [https://issues.jboss.org/browse/WFNOSQL-28?focusedCommentId=13643485&page...]
> Capability 'org.wildfly.nosql.mongo.driver-service' is unknown error thrown on WildFly 14 + current master branch
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4153
> URL: https://issues.jboss.org/browse/WFCORE-4153
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.1.Final
> Reporter: Scott Marlow
> Assignee: Jeff Mesnil
> Priority: Major
>
> As reported on [https://issues.jboss.org/browse/WFNOSQL-28], the wildfly-nosql subsystems are failing on WF14. I will try to work around the failure, following Brian's advice but would still like to see this resolved for other (externally created) subsystems that might hit it.
> Example of failure:
> {quote}
> 2018-10-04 11:09:17,904 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool – 10) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "mongodb"),("mongo" => "default"),("host" => "default")
> ]): java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.nosql.mongo.driver-service' is unknown.
> at org.jboss.as.controller.CapabilityReferenceRecorder$DefaultCapabilityReferenceRecorder.getDependentName(CapabilityReferenceRecorder.java:139)
> at org.jboss.as.controller.CapabilityReferenceRecorder$ContextDependencyRecorder.processCapabilityRequirement(CapabilityReferenceRecorder.java:196)
> at org.jboss.as.controller.CapabilityReferenceRecorder$ContextDependencyRecorder.addCapabilityRequirements(CapabilityReferenceRecorder.java:182)
> at org.jboss.as.controller.AttributeDefinition.addCapabilityRequirements(AttributeDefinition.java:1066)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:291)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:154)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (LOGMGR-52) Add option to WriterHandler to collapse repeated messages
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-52?page=com.atlassian.jira.plugin.... ]
James Perkins updated LOGMGR-52:
--------------------------------
Fix Version/s: (was: 2.1.5.Final)
> Add option to WriterHandler to collapse repeated messages
> ---------------------------------------------------------
>
> Key: LOGMGR-52
> URL: https://issues.jboss.org/browse/LOGMGR-52
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: David Lloyd
> Priority: Major
>
> The WriterHandler could have a time interval configured wherein a repeated message would be collapsed.
> The last message would be stored in a field for comparison along with a nanoTime tag (the timestamp on the message is not adequate because the clock can have skew or be reset completely at any time). If the current message string equals the last message string, and collapsing is enabled, then instead of logging the message, a count is incremented. If the current message is not equal, then the stored message is logged with a tag indicating the number of repeats (i18n?) and then the next submitted message is logged.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3053:
-------------------------------------
!warning2.png|thumbnail!
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
> Attachments: Screenshot from 2018-10-04 17-44-51.png, Screenshot from 2018-10-04 17-45-21.png
>
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
> - If the user try to update the column type with the same column type no warning should be raised and data should stay untouched
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3053:
--------------------------------
Attachment: warning2.png
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
> Attachments: Screenshot from 2018-10-04 17-44-51.png, Screenshot from 2018-10-04 17-45-21.png, warning2.png
>
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
> - If the user try to update the column type with the same column type no warning should be raised and data should stay untouched
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3053:
--------------------------------
Attachment: (was: warning2.png)
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
> Attachments: Screenshot from 2018-10-04 17-44-51.png, Screenshot from 2018-10-04 17-45-21.png, warning2.png
>
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
> - If the user try to update the column type with the same column type no warning should be raised and data should stay untouched
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months