Copilot commented on code in PR #4035:
URL: 
https://github.com/apache/incubator-kie-tools/pull/4035#discussion_r4268523233


##########
packages/bpmn-editor/src/propertiesPanel/dataMapping/DataMappingFormSection.tsx:
##########
@@ -782,9 +804,21 @@ export function useDataMapping(
       }
 
       bpmnEditorStoreApi.setState((s) => {
+        // Re-read the reserved entries that were stripped from the editable 
state
+        // so they are preserved through the save cycle.
+        const { inputDataMapping: modelInputDataMapping } = 
getDataMapping(element);
+        const reservedNamesForElement =
+          DATA_INPUT_RESERVED_NAMES.get(element.__$$element as 
Parameters<typeof DATA_INPUT_RESERVED_NAMES.get>[0]) ??
+          new Set<string>();
+        const reservedEntries = modelInputDataMapping.filter((d) => 
reservedNamesForElement.has(d.name));
+
+        // Exclude user-typed entries whose names match reserved names — they 
would
+        // collide with internal task inputs and must not be saved as user 
data mappings.
+        const userEntries = inputDataMapping.filter((d) => 
!reservedNamesForElement.has(d.name));
+
         setDataMappingForElement({
           definitions: s.bpmn.model.definitions,
-          inputDataMapping,
+          inputDataMapping: [...reservedEntries, ...userEntries],
           outputDataMapping,

Review Comment:
   The save-cycle preservation/exclusion logic only preserves/excludes reserved 
entries based on `DATA_INPUT_RESERVED_NAMES`. For custom tasks, 
`flaggedDataInputs()` can mark additional names as reserved, but this code will 
still persist user-provided entries with those reserved names (and may fail to 
preserve model-reserved entries for those custom tasks). Use the same 
reserved-name computation here as the UI validation (including `customTasks` 
wildcard/pattern matches), so reserved custom-task inputs are consistently 
preserved from the model and excluded from user entries.



##########
packages/bpmn-editor/src/propertiesPanel/dataMapping/DataMappingFormSection.tsx:
##########
@@ -761,15 +779,19 @@ export function useDataMapping(
     [inputDataMapping, outputDataMapping]
   );
 
-  // populates intermediary data mapping state from the model
+  // populates intermediary data mapping state from the model,
+  // stripping reserved entries so they never appear in the editable list.
   useEffect(() => {
     if (!element) {
       return;
     }
 
     const { inputDataMapping, outputDataMapping } = getDataMapping(element);
+    const reservedNamesForElement =
+      DATA_INPUT_RESERVED_NAMES.get(element.__$$element as Parameters<typeof 
DATA_INPUT_RESERVED_NAMES.get>[0]) ??
+      new Set<string>();

Review Comment:
   `element.__$$element as Parameters<typeof DATA_INPUT_RESERVED_NAMES.get>[0]` 
is hard to read and is duplicated (also reintroduced in the save path). 
Consider extracting a small helper (e.g., 
`getReservedDataInputNamesForElement(element)` or a predicate 
`isReservedDataInputName(name, element, customTasks)`) to (1) remove the 
repeated cast boilerplate and (2) ensure all reserved-name decisions remain 
consistent across UI, state initialization, and save.



##########
packages/bpmn-editor/src/propertiesPanel/dataMapping/DataMappingFormSection.tsx:
##########
@@ -761,15 +779,19 @@ export function useDataMapping(
     [inputDataMapping, outputDataMapping]
   );
 
-  // populates intermediary data mapping state from the model
+  // populates intermediary data mapping state from the model,
+  // stripping reserved entries so they never appear in the editable list.
   useEffect(() => {
     if (!element) {
       return;
     }
 
     const { inputDataMapping, outputDataMapping } = getDataMapping(element);
+    const reservedNamesForElement =
+      DATA_INPUT_RESERVED_NAMES.get(element.__$$element as Parameters<typeof 
DATA_INPUT_RESERVED_NAMES.get>[0]) ??
+      new Set<string>();
 
-    setInputDataMapping(inputDataMapping);
+    setInputDataMapping(inputDataMapping.filter((d) => 
!reservedNamesForElement.has(d.name)));
     setOutputDataMapping(outputDataMapping);

Review Comment:
   The “reserved” logic used to strip inputs from the editable state only 
consults `DATA_INPUT_RESERVED_NAMES`, but `flaggedDataInputs()` treats 
additional names as reserved via `customTasks` (including wildcard patterns). 
This mismatch means reserved custom-task inputs can still appear in the 
editable list (or be saved) even though the UI marks them as reserved. Align 
the filtering logic with `flaggedDataInputs()` by incorporating 
`customTasks`-based reserved-name evaluation (e.g., a shared predicate/helper 
used by both `flaggedDataInputs()` and `useDataMapping()`).



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to