[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3393:
--------------------------------------
In my opinion, using an icon would be redundant. The whole cell gets highlighted once it is detected as erroneous, so the distinction should be clear even for visually impaired users. I guess we could use for example a red "x" icon, but we would need to decide on the placement (before the cell content? After the cell content? What if the cell content is longer than the cell itself, then the icon might not even be visible.), which sounds too complicated to me for a situation where we already have a working solution.
> 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)
7 years, 5 months
[JBoss JIRA] (DROOLS-3406) [DMN Designer] Decision Service splitter should be movable
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3406?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3406:
-----------------------------------
Sprint: 2018 Week 48-50
> [DMN Designer] Decision Service splitter should be movable
> ----------------------------------------------------------
>
> Key: DROOLS-3406
> URL: https://issues.jboss.org/browse/DROOLS-3406
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> The _splitter_ within a Decision Service is static.
> It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2316:
--------------------------------
You're right; I'm updating the manual as we speak.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden
by Chao Wang (Jira)
[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ]
Chao Wang reassigned WFCORE-4239:
---------------------------------
Assignee: Chao Wang (was: Jeff Mesnil)
> WARN if system-property is already set and is being overridden
> --------------------------------------------------------------
>
> Key: WFCORE-4239
> URL: https://issues.jboss.org/browse/WFCORE-4239
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Priority: Major
>
> WARN if system-property is already set and is being overridden
> If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later.
> JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1"
> {code}
> <system-properties>
> <property name="my.system.property" value="value2"/>
> </system-properties>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Sebastian Łaskawiec (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2316:
-------------------------------------------
[~belaban] You're too fast :) I haven't had a chance to give you feedback :)
Yes, I like the idea. The only thing to remember is to set transport TCP port in the Service when using SRV records. This is essential!
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3234) Add a Donut widget to improve the visualisation of test report screen
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3234?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3234:
--------------------------------------
I thought we're going to discuss the improvements on GitHub, where I wrote my original comment, but let's just do it here. :-) My comment was:
bq. I only have two minor comments. Firstly, I noticed that the number of passed/failed tests shown directly in the donut is not an integer, but always 5.00, 4.00, 1.00, etc. Could this be fixed to 5, 4, 1, etc.? Secondly, it looks like once you mouse over the donut, its edges are somehow cropped, almost like there's not enough space for the chart. Can this be solved?
[~uxdlc], I agree with all your suggested improvements, the enhanced donut looks great. [~Rikkola], what do you think? Is it possible to implement them? Can we implement all/some of them directly in this PR? I can create a Jira for the ones that cannot be solved right away. Please let us know.
> Add a Donut widget to improve the visualisation of test report screen
> ---------------------------------------------------------------------
>
> Key: DROOLS-3234
> URL: https://issues.jboss.org/browse/DROOLS-3234
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Attachments: donut.png, screencast-04-12-18.webm
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2316.
----------------------------
Fix Version/s: 4.0.16
Resolution: Done
[~dmcnair] Can you try out my fix? Please reopen if the problem persists.
Cheers,
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3395) [DMN Designer] Two copies of node are created
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3395?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3395:
-------------------------------------
Still present on my master, lets compare environments at first:
- Google chrome
- eap 7.2
- jdk8
- business-central-parent module
> [DMN Designer] Two copies of node are created
> ---------------------------------------------
>
> Key: DROOLS-3395
> URL: https://issues.jboss.org/browse/DROOLS-3395
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Spotted during DROOLS-3371 review, however it is probably not related.
> If user copies diagram node by CTRL+C and CTRL+V it results two copies of the given node are created.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months