[JBoss JIRA] (DROOLS-4477) [DMN Designer] Decision Services - When a decision service is deleted all associated decisions are also deleted
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4477?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4477:
--------------------------------
Description:
When a decision service is deleted in the model, all associated decisions are deleted with it. The inner nodes shouldn't be deleted.
DMN Spec: “Decision services are defined as overlays and therefore do not encapsulate the decisions within them.“ (section 6.2.5, p44)
h3. Manual acceptance test
- Edges crossing ds (/)
- Edges outgoing from ds (/)
- Edges incoming to ds (/)
was:
When a decision service is deleted in the model, all associated decisions are deleted with it. The inner nodes shouldn't be deleted.
DMN Spec: “Decision services are defined as overlays and therefore do not encapsulate the decisions within them.“ (section 6.2.5, p44)
h3. Manual acceptance test
- Edges crossing ds
- Edges outgoing from ds
- Edges incoming to ds
> [DMN Designer] Decision Services - When a decision service is deleted all associated decisions are also deleted
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4477
> URL: https://issues.jboss.org/browse/DROOLS-4477
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> When a decision service is deleted in the model, all associated decisions are deleted with it. The inner nodes shouldn't be deleted.
> DMN Spec: “Decision services are defined as overlays and therefore do not encapsulate the decisions within them.“ (section 6.2.5, p44)
> h3. Manual acceptance test
> - Edges crossing ds (/)
> - Edges outgoing from ds (/)
> - Edges incoming to ds (/)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (DROOLS-4477) [DMN Designer] Decision Services - When a decision service is deleted all associated decisions are also deleted
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4477?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4477:
--------------------------------
Description:
When a decision service is deleted in the model, all associated decisions are deleted with it. The inner nodes shouldn't be deleted.
DMN Spec: “Decision services are defined as overlays and therefore do not encapsulate the decisions within them.“ (section 6.2.5, p44)
h3. Manual acceptance test
- Edges crossing ds
- Edges outgoing from ds
- Edges incoming to ds
was:
When a decision service is deleted in the model, all associated decisions are deleted with it. The inner nodes shouldn't be deleted.
DMN Spec: “Decision services are defined as overlays and therefore do not encapsulate the decisions within them.“ (section 6.2.5, p44)
> [DMN Designer] Decision Services - When a decision service is deleted all associated decisions are also deleted
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4477
> URL: https://issues.jboss.org/browse/DROOLS-4477
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> When a decision service is deleted in the model, all associated decisions are deleted with it. The inner nodes shouldn't be deleted.
> DMN Spec: “Decision services are defined as overlays and therefore do not encapsulate the decisions within them.“ (section 6.2.5, p44)
> h3. Manual acceptance test
> - Edges crossing ds
> - Edges outgoing from ds
> - Edges incoming to ds
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFWIP-167:
------------------------------------
I have created JBEAP-17559 to track documenting "standalone.xml via ConfigMap" is technical preview feature.
> EAP Operator handling ConfigMap internally
> ------------------------------------------
>
> Key: WFWIP-167
> URL: https://issues.jboss.org/browse/WFWIP-167
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> If I understand description in [1] correctly. To specify custom standalone.xml I have to create ConfigMap with standalone.xml first and afterwards link operator to this ConfigMap.
> Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally I just specify file URI where custom standalone.xml is located. This location have to be accessible from operator pod. In this way we can look at it as hiding internals (implementation details) from users.
> Currently when user wants to change standalone.xml he does in ConfigMap, not operator. When changing standalone.xml through config map, I assume pod have to be restarted manually. Operator could do that for me.
> However this can be triggered by storing newer version of standalone.xml under another key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator.
> What do you think? Have you considered this approach?
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months