[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2787:
----------------------------------------
[~uxdlc] Looks good, although I'm not keen on the "outdent arrow" icon to change the nesting of the new field. What if the "Add" button was context sensitive? So, if you had "Address" selected it'd add a child to Address, if you had "Employer" selected it'd add a child to Employer etc. If you selected tPerson3 it'd a new _root_ level field (this follows from Guilherme's suggestion of my comment about not having a "Data Type Name" text box, but the first row shows the data type name (and then name, age, Address, Employer etc are nested under that). See https://redhat.invisionapp.com/share/5WN6YR57PBV#/screens/311029287
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, treegrid.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (SWSQE-342) QE: Kiali move to Istio 1.0.0
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-342?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo reassigned SWSQE-342:
---------------------------------------------
Assignee: Guilherme Baufaker Rêgo (was: Michael Foley)
> QE: Kiali move to Istio 1.0.0
> -----------------------------
>
> Key: SWSQE-342
> URL: https://issues.jboss.org/browse/SWSQE-342
> Project: Kiali QE
> Issue Type: Story
> Reporter: Hayk Hovsepyan
> Assignee: Guilherme Baufaker Rêgo
>
> Kiali is going to be moved on Istio 1.0.0, dev branch is created for that.
> Early testing was completed from QE side.
> We need several tasks on QE side to adjust Pipeline, Bookinfo installation, checker job...
> This is umbrella task for Istio 1.0.0 moving.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro commented on DROOLS-2787:
--------------------------------------------
Thank you, [~uxdlc].
As commented on Slack. I have one concern: how does the user create a simple data type? (we have only the “Data Type Name” in the top and no field for specifying the type).
[~manstis] suggested that maybe _should be no "outer" name selector; but when first loading the dialog the table has one row that cannot be deleted. So when creating a type; you'd have 1 row by default where you specify the name (of the type) and it's type (built-in/already existing etc)_.
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, treegrid.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1616) ldap-key-store requires attribute userPKCS12 on ldap entry, even if it should be mandatory
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/ELY-1616?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek edited comment on ELY-1616 at 7/26/18 12:16 PM:
--------------------------------------------------------------
Issue is caused by missing configuration. Problem is caused by some ldap servers (OpenLdap in this case), which return "usercertificate;binary" as a result of search for "usercertificate".
If this happens, then ldap entry is not recognized as certificate without "userPKCS12" attribute.
Even if "userPKCS12" is defined, certificate is loaded from "userSMIMECertificate" attribute instead of "userCertificate" - so truststore works only if all 3 attributes are filled "userCertificate", "userSMIMECertificate" and "userPKCS12".
Solution is simple, use mapping for this kind of ldap servers, to search for "usercertificate;binary" instead of "usercertificate".
{quote}/subsystem=elytron/ldap-key-store=qsTrustStore:add( \
dir-context=exampleDC, \
search-path="ou=trusstore,dc=example,dc=org", \
certificate-attribute="*userCertificate;binary*", \
){quote}
With this mapping ldap trusstore will work without "userPKCS12" attributes (and also without "userSMIMECertificate")
was (Author: jondruse):
Issue is caused by missing configuration. Problem is caused by some ldap servers (OpenLdap in this case), which return "usercertificate;binary" as a result of search for "usercertificate".
If this happens, then ldap entry is not recognized as certificate without "userPKCS12" attribute.
Even if "userPKCS12" is defined, certificate is loaded from "userSMIMECertificate" attribute instead of "userCertificate" - so truststore works only if all 3 attribute are filled "userCertificate", "userSMIMECertificate" and "userPKCS12".
Solution is simple, use mapping for this kind of ldap servers, to search for "usercertificate;binary" instead of "usercertificate".
{quote}/subsystem=elytron/ldap-key-store=qsTrustStore:add( \
dir-context=exampleDC, \
search-path="ou=trusstore,dc=example,dc=org", \
certificate-chain-attribute="*userCertificate;binary*", \
){quote}
With this mapping ldap trusstore will work without "userPKCS12" attributes (and also without "userSMIMECertificate")
> ldap-key-store requires attribute userPKCS12 on ldap entry, even if it should be mandatory
> ------------------------------------------------------------------------------------------
>
> Key: ELY-1616
> URL: https://issues.jboss.org/browse/ELY-1616
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.11.CR1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
>
> The "key-attribute" ("userPKCS12") should not be necessary to use LdapKeyStore as truststore.
> See Steps to Reproduce for more information.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1616) ldap-key-store requires attribute userPKCS12 on ldap entry, even if it should be mandatory
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/ELY-1616?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek edited comment on ELY-1616 at 7/26/18 12:13 PM:
--------------------------------------------------------------
Issue is caused by missing configuration. Problem is caused by some ldap servers (OpenLdap in this case), which return "usercertificate;binary" as a result of search for "usercertificate".
If this happens, then ldap entry is not recognized as certificate without "userPKCS12" attribute.
Even if "userPKCS12" is defined, certificate is loaded from "userSMIMECertificate" attribute instead of "userCertificate" - so truststore works only if all 3 attribute are filled "userCertificate", "userSMIMECertificate" and "userPKCS12".
Solution is simple, use mapping for this kind of ldap servers, to search for "usercertificate;binary" instead of "usercertificate".
{quote}/subsystem=elytron/ldap-key-store=qsTrustStore:add( \
dir-context=exampleDC, \
search-path="ou=trusstore,dc=example,dc=org", \
certificate-chain-attribute="*userCertificate;binary*", \
){quote}
With this mapping ldap trusstore will work without "userPKCS12" attributes (and also without "userSMIMECertificate")
was (Author: jondruse):
Issue is caused by missing configuration. Problem is caused by some ldap servers (OpenLdap in this case), which return "usercertificate;binary" as a result of search for "usercertificate".
If this happens, then ldap entry is not recognized as certificate without "userPKCS12" attribute.
Solution is simple, use mapping for this kind of ldap servers, to search for "usercertificate;binary" instead of "usercertificate".
{quote}/subsystem=elytron/ldap-key-store=qsTrustStore:add( \
dir-context=exampleDC, \
search-path="ou=trusstore,dc=example,dc=org", \
certificate-chain-attribute="*userCertificate;binary*", \
){quote}
With this mapping ldap trusstore will work without "userPKCS12" attributes.
> ldap-key-store requires attribute userPKCS12 on ldap entry, even if it should be mandatory
> ------------------------------------------------------------------------------------------
>
> Key: ELY-1616
> URL: https://issues.jboss.org/browse/ELY-1616
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.11.CR1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
>
> The "key-attribute" ("userPKCS12") should not be necessary to use LdapKeyStore as truststore.
> See Steps to Reproduce for more information.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (ELY-1616) ldap-key-store requires attribute userPKCS12 on ldap entry, even if it should be mandatory
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/ELY-1616?page=com.atlassian.jira.plugin.s... ]
Jiri Ondrusek commented on ELY-1616:
------------------------------------
Issue is caused by missing configuration. Problem is caused by some ldap servers (OpenLdap in this case), which return "usercertificate;binary" as a result of search for "usercertificate".
If this happens, then ldap entry is not recognized as certificate without "userPKCS12" attribute.
Solution is simple, use mapping for this kind of ldap servers, to search for "usercertificate;binary" instead of "usercertificate".
{quote}/subsystem=elytron/ldap-key-store=qsTrustStore:add( \
dir-context=exampleDC, \
search-path="ou=trusstore,dc=example,dc=org", \
certificate-chain-attribute="*userCertificate;binary*", \
){quote}
With this mapping ldap trusstore will work without "userPKCS12" attributes.
> ldap-key-store requires attribute userPKCS12 on ldap entry, even if it should be mandatory
> ------------------------------------------------------------------------------------------
>
> Key: ELY-1616
> URL: https://issues.jboss.org/browse/ELY-1616
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.11.CR1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
>
> The "key-attribute" ("userPKCS12") should not be necessary to use LdapKeyStore as truststore.
> See Steps to Reproduce for more information.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10747) IOException when using JSF in deployment
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-10747?page=com.atlassian.jira.plugin... ]
Farah Juma commented on WFLY-10747:
-----------------------------------
Does this still happen with the WildFly master branch, which is currently on Mojarra 2.3.5?
> IOException when using JSF in deployment
> ----------------------------------------
>
> Key: WFLY-10747
> URL: https://issues.jboss.org/browse/WFLY-10747
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Reporter: Adam Krajcik
> Assignee: Farah Juma
> Attachments: deployment.war
>
>
> When using JSF in attached [^deployment.war], I can see the following error. This error happens during the first request. Sever doesn't print this error on further requests.
> {code}
> 14:08:31,401 SEVERE [facelets.compiler] (default task-1) Error Loading Library: jar:file:/tmp/jboss-eap-7.2/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP5-redhat-1.jar!/META-INF/mojarra_ext.taglib.xml: java.io.IOException: Error parsing [jar:file:/tmp/jboss-eap-7.2/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP5-redhat-1.jar!/META-INF/mojarra_ext.taglib.xml]:
> at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:410)
> at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:431)
> at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
> at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
> at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:218)
> at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:149)
> at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:100)
> at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:519)
> at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:569)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
> 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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> 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:1349)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXException: Error Handling [jar:file:/tmp/jboss-eap-7.2/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP5-redhat-1.jar!/META-INF/mojarra_ext.taglib.xml@47,31]
> at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLibraryConfig.java:376)
> at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(XMLDTDValidator.java:1644)
> at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:1922)
> at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:787)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:827)
> at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:1141)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(SAXParserImpl.java:298)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
> at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:407)
> ... 53 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months