[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Stetson Robinson (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Stetson Robinson edited comment on DROOLS-2706 at 7/6/18 12:05 PM:
-------------------------------------------------------------------
[~uxdlc], I think there are two distinctions we're trying to make, from what I understand. One is to distinguish the new Rule Scenario Test asset from the current Test Scenario asset, which is what I believer you're addressing. For that distinction, I'd vote "Rule Scenario Test" and "Test Scenario (Legacy)", the latter to be replaced by the former, eventually. The other distinction as [~Rikkola] mentioned is between the initial "Technology Preview" version of the Rule Scenario Test asset to go in 7.1 alongside the current Test Scenario asset, and the complete, stable version delivered later in 7.2. "Technology Preview" is the standard term we use for currently unsupported or incomplete features, so it make sense to me to use that. It's important to make that clear because if users use this new Tech Preview version of the Rule Scenario Test asset in 7.1 in its maiden and incomplete form, the scenarios they create with it might not survive the update to its completed and stable form that is released thereafter, in 7.2 or whenever.
So here's the naming/phasing I'd propose:
# When the Rule Scenario Test is launched initially and is incomplete, say in DM/PAM 7.1, we call the two scenario assets *Rule Scenario Test (Preview)* and *Test Scenario*. We wouldn't indicate anything is legacy at this point (odd to have a legacy and preview version of a feature with no stable alternative), and we could include a small info icon for the Preview asset and any other Preview assets to indicate what Technology Preview means. I'll provide that because we use the definition throughout our docs anyway.
# Then when the new asset is complete and stable with no risk of losing data going forward, say in DM/PAM 7.2, we call the two assets *Rule Scenario Test* and *Test Scenario (Legacy)*.
# Then at some point we provide a migration path for `.scenario` files from Test Scenarios to Rule Scenario Tests, and then phase out the legacy Test Scenario completely.
I'm open to other suggestions. Just my thoughts. What do we think?
was (Author: stetson.robinson):
[~uxdlc], I think there are two distinctions we're trying to make, from what I understand. One is to distinguish the new Rule Scenario Test asset from the current Test Scenario asset, which is what you're addressing. For that distinction, I'd vote "Rule Scenario Test" and "Test Scenario (Legacy)", the latter to be replaced by the former, eventually. The other distinction as [~Rikkola] mentioned is between the initial "Technology Preview" version of the Rule Scenario Test asset to go in 7.1 alongside the current Test Scenario asset, and the complete, stable version delivered later in 7.2. "Technology Preview" is the standard term we use for currently unsupported or incomplete features, so it make sense to me to use that. It's important to make that clear because if users use this new Tech Preview version of the Rule Scenario Test asset in 7.1 in its maiden and incomplete form, the scenarios they create with it might not survive the update to its completed and stable form that is released thereafter, in 7.2 or whenever.
So here's the naming/phasing I'd propose:
# When the Rule Scenario Test is launched initially and is incomplete, say in DM/PAM 7.1, we call the two scenario assets *Rule Scenario Test (Preview)* and *Test Scenario*. We wouldn't indicate anything is legacy at this point (odd to have a legacy and preview version of a feature with no stable alternative), and we could include a small info icon for the Preview asset and any other Preview assets to indicate what Technology Preview means. I'll provide that because we use the definition throughout our docs anyway.
# Then when the new asset is complete and stable with no risk of losing data going forward, say in DM/PAM 7.2, we call the two assets *Rule Scenario Test* and *Test Scenario (Legacy)*.
# Then at some point we provide a migration path for `.scenario` files from Test Scenarios to Rule Scenario Tests, and then phase out the legacy Test Scenario completely.
I'm open to other suggestions. Just my thoughts. What do we think?
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Stetson Robinson (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Stetson Robinson edited comment on DROOLS-2706 at 7/6/18 12:05 PM:
-------------------------------------------------------------------
[~uxdlc], I think there are two distinctions we're trying to make, from what I understand. One is to distinguish the new Rule Scenario Test asset from the current Test Scenario asset, which is what I believe you're addressing. For that distinction, I'd vote "Rule Scenario Test" and "Test Scenario (Legacy)", the latter to be replaced by the former, eventually. The other distinction as [~Rikkola] mentioned is between the initial "Technology Preview" version of the Rule Scenario Test asset to go in 7.1 alongside the current Test Scenario asset, and the complete, stable version delivered later in 7.2. "Technology Preview" is the standard term we use for currently unsupported or incomplete features, so it make sense to me to use that. It's important to make that clear because if users use this new Tech Preview version of the Rule Scenario Test asset in 7.1 in its maiden and incomplete form, the scenarios they create with it might not survive the update to its completed and stable form that is released thereafter, in 7.2 or whenever.
So here's the naming/phasing I'd propose:
# When the Rule Scenario Test is launched initially and is incomplete, say in DM/PAM 7.1, we call the two scenario assets *Rule Scenario Test (Preview)* and *Test Scenario*. We wouldn't indicate anything is legacy at this point (odd to have a legacy and preview version of a feature with no stable alternative), and we could include a small info icon for the Preview asset and any other Preview assets to indicate what Technology Preview means. I'll provide that because we use the definition throughout our docs anyway.
# Then when the new asset is complete and stable with no risk of losing data going forward, say in DM/PAM 7.2, we call the two assets *Rule Scenario Test* and *Test Scenario (Legacy)*.
# Then at some point we provide a migration path for `.scenario` files from Test Scenarios to Rule Scenario Tests, and then phase out the legacy Test Scenario completely.
I'm open to other suggestions. Just my thoughts. What do we think?
was (Author: stetson.robinson):
[~uxdlc], I think there are two distinctions we're trying to make, from what I understand. One is to distinguish the new Rule Scenario Test asset from the current Test Scenario asset, which is what I believer you're addressing. For that distinction, I'd vote "Rule Scenario Test" and "Test Scenario (Legacy)", the latter to be replaced by the former, eventually. The other distinction as [~Rikkola] mentioned is between the initial "Technology Preview" version of the Rule Scenario Test asset to go in 7.1 alongside the current Test Scenario asset, and the complete, stable version delivered later in 7.2. "Technology Preview" is the standard term we use for currently unsupported or incomplete features, so it make sense to me to use that. It's important to make that clear because if users use this new Tech Preview version of the Rule Scenario Test asset in 7.1 in its maiden and incomplete form, the scenarios they create with it might not survive the update to its completed and stable form that is released thereafter, in 7.2 or whenever.
So here's the naming/phasing I'd propose:
# When the Rule Scenario Test is launched initially and is incomplete, say in DM/PAM 7.1, we call the two scenario assets *Rule Scenario Test (Preview)* and *Test Scenario*. We wouldn't indicate anything is legacy at this point (odd to have a legacy and preview version of a feature with no stable alternative), and we could include a small info icon for the Preview asset and any other Preview assets to indicate what Technology Preview means. I'll provide that because we use the definition throughout our docs anyway.
# Then when the new asset is complete and stable with no risk of losing data going forward, say in DM/PAM 7.2, we call the two assets *Rule Scenario Test* and *Test Scenario (Legacy)*.
# Then at some point we provide a migration path for `.scenario` files from Test Scenarios to Rule Scenario Tests, and then phase out the legacy Test Scenario completely.
I'm open to other suggestions. Just my thoughts. What do we think?
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Stetson Robinson (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Stetson Robinson commented on DROOLS-2706:
------------------------------------------
[~uxdlc], I think there are two distinctions we're trying to make, from what I understand. One is to distinguish the new Rule Scenario Test asset from the current Test Scenario asset, which is what you're addressing. For that distinction, I'd vote "Rule Scenario Test" and "Test Scenario (Legacy)", the latter to be replaced by the former, eventually. The other distinction as [~Rikkola] mentioned is between the initial "Technology Preview" version of the Rule Scenario Test asset to go in 7.1 alongside the current Test Scenario asset, and the complete, stable version delivered later in 7.2. "Technology Preview" is the standard term we use for currently unsupported or incomplete features, so it make sense to me to use that. It's important to make that clear because if users use this new Tech Preview version of the Rule Scenario Test asset in 7.1 in its maiden and incomplete form, the scenarios they create with it might not survive the update to its completed and stable form that is released thereafter, in 7.2 or whenever.
So here's the naming/phasing I'd propose:
# When the Rule Scenario Test is launched initially and is incomplete, say in DM/PAM 7.1, we call the two scenario assets *Rule Scenario Test (Preview)* and *Test Scenario*. We wouldn't indicate anything is legacy at this point (odd to have a legacy and preview version of a feature with no stable alternative), and we could include a small info icon for the Preview asset and any other Preview assets to indicate what Technology Preview means. I'll provide that because we use the definition throughout our docs anyway.
# Then when the new asset is complete and stable with no risk of losing data going forward, say in DM/PAM 7.2, we call the two assets *Rule Scenario Test* and *Test Scenario (Legacy)*.
# Then at some point we provide a migration path for `.scenario` files from Test Scenarios to Rule Scenario Tests, and then phase out the legacy Test Scenario completely.
I'm open to other suggestions. Just my thoughts. What do we think?
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Stetson Robinson (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Stetson Robinson edited comment on DROOLS-2706 at 7/6/18 11:38 AM:
-------------------------------------------------------------------
[~uxdlc], [~mstevens1], [~ibek], we should also make sure we all agree on the name for this new asset. Various names are floating around: "Scenario Simulation", "Scenario Test", etc. IMO, I think we should consider *"Rule Scenario Test"* or the like, to make it clearest. Might require additional discussion, which I think we should have.
was (Author: stetson.robinson):
[~uxdlc], [~mstevens1], [~ibek], we should also make sure we all agree on the name for this new asset. Various names are floating around: "Scenario Simulation", "Scenario Test", etc. IMO, I think we should consider *"Rules Scenario Test"* or the like, to make it clearest. Might require additional discussion, which I think we should have.
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10553) (doc) CLIENT_CERT without users certificates database
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-10553?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFLY-10553:
------------------------------------
Fix Version/s: 14.0.0.CR1
> (doc) CLIENT_CERT without users certificates database
> -----------------------------------------------------
>
> Key: WFLY-10553
> URL: https://issues.jboss.org/browse/WFLY-10553
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation
> Affects Versions: 13.0.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Fix For: 14.0.0.CR1
>
>
> CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them.
> As client cetificate is already checked by SSLContext, certificate verification in CLIENT-CERT HTTP mechanism should be made optional. (Need to be enabled by default for backward compatibility.)
> Analysis document:
> https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years