November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3030) [DMN Designer] Expand / Collapse all

by Guilherme Carreiro (Jira)

[ https://issues.jboss.org/browse/DROOLS-3030?page=com.atlassian.jira.plugi... ] Guilherme Carreiro reopened DROOLS-3030: ---------------------------------------- > [DMN Designer] Expand / Collapse all > ------------------------------------ > > Key: DROOLS-3030 > URL: https://issues.jboss.org/browse/DROOLS-3030 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.12.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Carreiro > Priority: Major > Labels: UX, drools-tools > > User should have possibility to easily expand / collapse all data types in the *manage custom data type* dialog. > h2. Manual acceptance test > - Expand > -- All collapsed initially > -- Something collapsed initially, something expanded already > -- All expanded already > - Collapse > -- All expanded initially > -- Something expanded initially, something collapsed already > -- All collapsed already > - No error warning in browser console log -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3049) [DMN Designer] NameAndDataTypeEditorViewImpl needs to hide if the User navigates to the Data Type dialog

by Guilherme Carreiro (Jira)

[ https://issues.jboss.org/browse/DROOLS-3049?page=com.atlassian.jira.plugi... ] Guilherme Carreiro commented on DROOLS-3049: -------------------------------------------- Resolved by this PR https://github.com/kiegroup/kie-wb-common/pull/2314. > [DMN Designer] NameAndDataTypeEditorViewImpl needs to hide if the User navigates to the Data Type dialog > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3049 > URL: https://issues.jboss.org/browse/DROOLS-3049 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.12.0.Final > Reporter: Michael Anstis > Assignee: Guilherme Carreiro > Priority: Minor > > The {{NameAndDataTypeEditorViewImpl}} contains a link to the "Data Type Dialog". When this is clicked on the dialog is displayed and the _source_ {{Popover}} remains visible. When the User clicks on the dialog a mouse event is detected that is not _over_ the {{Popover}} and it closes. The proposal is to close the {{Popover}} if the User clicks on the link to the "Data Type Dialog". -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-3393: -------------------------------- Attachment: Screenshot from 2018-11-30 17-11-43.png > Please review scenario error cell text for legibility/accessibility. > --------------------------------------------------------------------- > > Key: DROOLS-3393 > URL: https://issues.jboss.org/browse/DROOLS-3393 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Klara Kufova > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screenshot from 2018-11-30 17-11-43.png > > > [~kkufova] [~bdellasc] > I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. > I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. > I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. > Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-3393: -------------------------------- Attachment: Screen Shot 2018-11-30 at 12.05.50 PM.png > Please review scenario error cell text for legibility/accessibility. > --------------------------------------------------------------------- > > Key: DROOLS-3393 > URL: https://issues.jboss.org/browse/DROOLS-3393 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Klara Kufova > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screenshot from 2018-11-30 17-11-43.png > > > [~kkufova] [~bdellasc] > I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. > I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. > I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. > Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-3393: -------------------------------- Attachment: Screen Shot 2018-11-30 at 11.59.32 AM.png > Please review scenario error cell text for legibility/accessibility. > --------------------------------------------------------------------- > > Key: DROOLS-3393 > URL: https://issues.jboss.org/browse/DROOLS-3393 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Klara Kufova > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screenshot from 2018-11-30 17-11-43.png > > > [~kkufova] [~bdellasc] > I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. > I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. > I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. > Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

Liz Clayton created DROOLS-3393: ----------------------------------- Summary: Please review scenario error cell text for legibility/accessibility. Key: DROOLS-3393 URL: https://issues.jboss.org/browse/DROOLS-3393 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Reporter: Liz Clayton Assignee: Klara Kufova [~kkufova] [~bdellasc] I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] Stefan Guilhen closed SECURITY-868. ----------------------------------- Resolution: Done > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Priority: Major > Fix For: PicketBox_4_9_0.Final > > Attachments: stacktraces.log > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-888) Revert changes made in SECURITY-868

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/SECURITY-888?page=com.atlassian.jira.plug... ] Stefan Guilhen closed SECURITY-888. ----------------------------------- Resolution: Done > Revert changes made in SECURITY-868 > ----------------------------------- > > Key: SECURITY-888 > URL: https://issues.jboss.org/browse/SECURITY-888 > Project: PicketBox > Issue Type: Task > Affects Versions: PicketBox_4_9_1.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Priority: Major > Fix For: PicketBox_4_9_2.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-701) Wrong character table in Base64Utils

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/SECURITY-701?page=com.atlassian.jira.plug... ] Stefan Guilhen reassigned SECURITY-701: --------------------------------------- Assignee: (was: Stefan Guilhen) > Wrong character table in Base64Utils > ------------------------------------ > > Key: SECURITY-701 > URL: https://issues.jboss.org/browse/SECURITY-701 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_4_0_12.Final > Reporter: wiktorowski maximilien > Priority: Major > > In picketbox-4.0.7.Final.jar org.jboss.security.Base64Utils has a wrong character table > private static final char[] base64Table = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz./".toCharArray(); > It should be > private static final char[] base64Table = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/".toCharArray(); -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1223) jboss-ejb-iiop_1_0.xsd does not match Java implementation

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/WFLY-1223?page=com.atlassian.jira.plugin.... ] Stefan Guilhen reassigned WFLY-1223: ------------------------------------ Assignee: (was: Stefan Guilhen) > jboss-ejb-iiop_1_0.xsd does not match Java implementation > --------------------------------------------------------- > > Key: WFLY-1223 > URL: https://issues.jboss.org/browse/WFLY-1223 > Project: WildFly > Issue Type: Task > Components: IIOP > Reporter: david.boeren > Priority: Minor > > There's a mismatch between the schema file in > docs/schema/jboss-ejb-iiop_1_0.xsd and the java classes that implement > the parsing of this schema. As is usual in such cases, it's probably > the documentation that is wrong. > In the xsd file the children are described as attributes: > <xs:complexType name="iorTransportConfigType"> > <xs:annotation> > <xs:documentation> > <![CDATA[ > The iorTransportConfigType specifies attributes that can > be used to configure the transport requirements of > an IIOP enabled EJB3 bean. > * integrity: indicates if the server (target) supports > integrity protected messages. The valid values are > NONE, SUPPORTED or REQUIRED. > * confidentiality: indicates if the server (target) > supports privacy protected messages. The values are > NONE, SUPPORTED or REQUIRED. > * detect-misordering: indicates if the server (target) > supports detection of message sequence errors. The > values are NONE, SUPPORTED or REQUIRED. > * detect-replay: indicates if the server (target) supports > detection of message replay attempts. The values > are NONE, SUPPORTED or REQUIRED. > * establish-trust-in-client: indicates if the target is > capable of authenticating a client. The values are > NONE, SUPPORTED or REQUIRED. > * establish-trust-in-target: indicates if the target is > capable of authenticating to a client. The values > are NONE or SUPPORTED. > ]]> > </xs:documentation> > </xs:annotation> > <xs:attribute name="integrity" type="xs:string" use="required" > default="NONE"/> > <xs:attribute name="confidentiality" type="xs:string" > use="required" default="NONE"/> > <xs:attribute name="detect-misordering" type="xs:string" > use="optional" default="NONE"/> > <xs:attribute name="detect-replay" type="xs:string" > use="optional" default="NONE"/> > <xs:attribute name="establish-trust-in-client" type="xs:string" > use="required" default="NONE"/> > <xs:attribute name="establish-trust-in-target" type="xs:string" > use="required" default="NONE"/> > </xs:complexType> > However, in the class > (org.jboss.metadata.ejb.parser.jboss.ejb3.IIOPMetaDataParser) it > requires no attributes and expects to see these same children as elements: > protected IORTransportConfigMetaData > processTransportConfig(XMLStreamReader reader, final PropertyReplacer > propertyReplacer) throws XMLStreamException { > // the transport-config element doesn't have attributes. > requireNoAttributes(reader); > EnumSet<Element> requiredElements = EnumSet.of(Element.INTEGRITY, > Element.CONFIDENTIALITY, > Element.ESTABLISH_TRUST_IN_CLIENT, Element.ESTABLISH_TRUST_IN_TARGET); > IORTransportConfigMetaData transportConfig = new > IORTransportConfigMetaData(); > // process the transport config elements. > while (reader.hasNext() && reader.nextTag() != END_ELEMENT) { > Element element = Element.forName(reader.getLocalName()); > // set the element text in the transport config metadata. > switch (element) { > case INTEGRITY: { > requireNoAttributes(reader); > transportConfig.setIntegrity(getElementText(reader, propertyReplacer)); > break; > } > case CONFIDENTIALITY: { > requireNoAttributes(reader); > transportConfig.setConfidentiality(getElementText(reader, > propertyReplacer)); > break; > } > case DETECT_MISORDERING: { > requireNoAttributes(reader); > transportConfig.setDetectMisordering(getElementText(reader, > propertyReplacer)); > break; > } > case DETECT_REPLAY: { > requireNoAttributes(reader); > transportConfig.setDetectReplay(getElementText(reader, propertyReplacer)); > break; > } > case ESTABLISH_TRUST_IN_CLIENT: { > requireNoAttributes(reader); > transportConfig.setEstablishTrustInClient(getElementText(reader, > propertyReplacer)); > break; > } > case ESTABLISH_TRUST_IN_TARGET: { > requireNoAttributes(reader); > transportConfig.setEstablishTrustInTarget(getElementText(reader, > propertyReplacer)); > break; > } > default: { > throw unexpectedElement(reader); > } > } > requiredElements.remove(element); > } > // throw an exception if a required element wasn't found. > if (!requiredElements.isEmpty()) { > throw missingRequiredElement(reader, requiredElements); > } > return transportConfig; > } -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2018