sartography
/
cr-connect-workflow
mirror of https://github.com/sartography/cr-connect-workflow.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
cr-connect-workflow/tests/data/test_value_expression/test_value_expression.bpmn

99 lines
5.1 KiB
Plaintext
Raw Normal View History

We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
<?xml version="1.0" encoding="UTF-8"?>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:camunda="http://camunda.org/schema/1.0/bpmn" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_0l37fag" targetNamespace="http://bpmn.io/schema/bpmn" exporter="Camunda Modeler" exporterVersion="3.7.3">
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
<bpmn:process id="Process_TestValueExpression" name="Test Value Expression" isExecutable="true">
<bpmn:startEvent id="StartEvent_1">
<bpmn:outgoing>Flow_1nc3qi5</bpmn:outgoing>
</bpmn:startEvent>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmn:sequenceFlow id="Flow_1nc3qi5" sourceRef="StartEvent_1" targetRef="Activity_Set_Expression" />
<bpmn:sequenceFlow id="Flow_1t2lo17" sourceRef="Activity_Set_Expression" targetRef="Activity_PreData" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
<bpmn:sequenceFlow id="Flow_1hhfj67" sourceRef="Activity_PreData" targetRef="Activity_Data" />
<bpmn:scriptTask id="Activity_PreData" name="Pre Data">
<bpmn:incoming>Flow_1t2lo17</bpmn:incoming>
<bpmn:outgoing>Flow_1hhfj67</bpmn:outgoing>
<bpmn:script>if not 'value_expression_value' in globals():
value_expression_value = ""</bpmn:script>
</bpmn:scriptTask>
<bpmn:userTask id="Activity_Data" name="Data" camunda:formKey="DataForm">
<bpmn:extensionElements>
<camunda:formData>
<camunda:formField id="color" label="Select" type="enum">
<camunda:properties>
<camunda:property id="value_expression" value="value_expression_value" />
</camunda:properties>
<camunda:value id="black" name="Black" />
<camunda:value id="white" name="White" />
</camunda:formField>
</camunda:formData>
</bpmn:extensionElements>
<bpmn:incoming>Flow_1hhfj67</bpmn:incoming>
<bpmn:outgoing>Flow_1skkg5a</bpmn:outgoing>
</bpmn:userTask>
<bpmn:sequenceFlow id="Flow_1skkg5a" sourceRef="Activity_Data" targetRef="Activity_GoodBye" />
<bpmn:manualTask id="Activity_GoodBye" name="Good Bye">
<bpmn:documentation>&lt;H1&gt;Good Bye&lt;/H1&gt;</bpmn:documentation>
<bpmn:incoming>Flow_1skkg5a</bpmn:incoming>
<bpmn:outgoing>Flow_057as2q</bpmn:outgoing>
</bpmn:manualTask>
<bpmn:endEvent id="Event_06wbkzi">
<bpmn:incoming>Flow_057as2q</bpmn:incoming>
</bpmn:endEvent>
<bpmn:sequenceFlow id="Flow_057as2q" sourceRef="Activity_GoodBye" targetRef="Event_06wbkzi" />
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmn:userTask id="Activity_Set_Expression" name="Hello" camunda:formKey="value_expression_form">
<bpmn:documentation>&lt;H1&gt;Hello&lt;/H1&gt;</bpmn:documentation>
<bpmn:extensionElements>
<camunda:formData>
<camunda:formField id="value_expression_value" type="string">
<camunda:validation>
<camunda:constraint name="required" config="true" />
</camunda:validation>
</camunda:formField>
</camunda:formData>
</bpmn:extensionElements>
<bpmn:incoming>Flow_1nc3qi5</bpmn:incoming>
<bpmn:outgoing>Flow_1t2lo17</bpmn:outgoing>
</bpmn:userTask>
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmn:process>
<bpmndi:BPMNDiagram id="BPMNDiagram_1">
<bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Process_TestValueExpression">
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmndi:BPMNEdge id="Flow_057as2q_di" bpmnElement="Flow_057as2q">
<di:waypoint x="850" y="117" />
<di:waypoint x="912" y="117" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmndi:BPMNEdge>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmndi:BPMNEdge id="Flow_1skkg5a_di" bpmnElement="Flow_1skkg5a">
<di:waypoint x="690" y="117" />
<di:waypoint x="750" y="117" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmndi:BPMNEdge>
<bpmndi:BPMNEdge id="Flow_1hhfj67_di" bpmnElement="Flow_1hhfj67">
<di:waypoint x="531" y="117" />
<di:waypoint x="590" y="117" />
</bpmndi:BPMNEdge>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmndi:BPMNEdge id="Flow_1t2lo17_di" bpmnElement="Flow_1t2lo17">
<di:waypoint x="370" y="117" />
<di:waypoint x="431" y="117" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmndi:BPMNEdge>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmndi:BPMNEdge id="Flow_1nc3qi5_di" bpmnElement="Flow_1nc3qi5">
<di:waypoint x="215" y="117" />
<di:waypoint x="270" y="117" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmndi:BPMNEdge>
<bpmndi:BPMNShape id="_BPMNShape_StartEvent_2" bpmnElement="StartEvent_1">
<dc:Bounds x="179" y="99" width="36" height="36" />
</bpmndi:BPMNShape>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmndi:BPMNShape id="Activity_115dslj_di" bpmnElement="Activity_PreData">
<dc:Bounds x="431" y="77" width="100" height="80" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="Activity_1i60o9l_di" bpmnElement="Activity_Data">
<dc:Bounds x="590" y="77" width="100" height="80" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="Activity_1b8d6dc_di" bpmnElement="Activity_GoodBye">
<dc:Bounds x="750" y="77" width="100" height="80" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape id="Event_06wbkzi_di" bpmnElement="Event_06wbkzi">
<dc:Bounds x="912" y="99" width="36" height="36" />
</bpmndi:BPMNShape>
My privous efforts didn't take into account the fact that we use dot notation in field names. I've re-worked the workflow form endpoint, so that it only accepts the data that should be in the form, and ignores any other values that come back from the front end. It seems Formly has some bugs that were introducing confusing information, and I want everything to behave consistently. I had to re-work some of the tests, which were relying on an ability to set data through a form post without having a corresponding form to do so.
2021-03-14 16:20:39 +00:00
<bpmndi:BPMNShape id="Activity_1wwwyog_di" bpmnElement="Activity_Set_Expression">
<dc:Bounds x="270" y="77" width="100" height="80" />
We now allow value_expression to evaluate to an empty string ("") so that we *do not* set a default value for enums in some cases. This was causing an error because "" was not an option for the enum.
2021-02-10 19:35:58 +00:00
</bpmndi:BPMNShape>
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
</bpmn:definitions>