Changes Marked as Pending After User Restores Original Value (updateGroup)

[marc4F]

Description:
When using an OData V4 model with two-way binding and an updateGroup, if a user changes a property and then manually sets it back to its original value, hasPendingChanges() still returns true. This results in unnecessary backend requests, even though there are no actual modifications left.

Steps to Reproduce:

1. Configure an OData V4 Binding with an updateGroup.
2. Bind (e.g., value of Input) to an OData V4 model property using two-way binding.
3. Change the input’s value from the original (e.g., "ABC") to a new value (e.g., "DEF").
4. Change the input’s value back to the original value ("ABC").
5. Call hasPendingChanges().

Expected Behavior:

• After restoring the original value, hasPendingChanges() should return false.
• No unnecessary backend requests should occur if no effective changes remain.

Actual Behavior:

• After restoring the original value, hasPendingChanges() returns true.
• Unnecessary backend requests are triggered when submitting the updateGroup changes.

Impact:

• Causes redundant server requests and additional load.
• Confuses users and developers, suggesting data is still modified.
• Complicates the process of batching changes.

Environment:

• UI5 version: 1.120.8
• OData V4 Backend: RAP with CDS

Additional Notes:

• Manual handling or resetting changes is required as a workaround.

Requested Fix:

• Improve the internal change tracking for updateGroup scenarios so that restoring a property to its original value is correctly recognized as no pending change.
• Ensure hasPendingChanges() accurately reflects actual modifications.

[ndeshev]

Hello @marc4F, I've created an internal incident DINC0366784. The status of the issue will be updated here in GitHub.

[marc4F]

Hello @ndeshev. Thanks for updates on the incident!

In the meantime, is there a way to retrieve the original value that was initially fetched from the backend before any user modifications?
If I can access the original value from the binding, I can compare it with the current (potentially changed) value and then call resetChanges if they match, effectively avoiding unnecessary updates.

[ndeshev]

Hello @marc4F could you please provide a minimal sample using this template for example, it will help speeding up the processing of the request.

[marc4F]

Please see the attached code. It should be enough to demonstrate the problem.

How to Test:

1. Replace <serviceUrl>, <entitySet>, and <property> with valid entries for your OData V4 service.
2. Start the application and note the original value of the Input.
3. Change the Input value to something else.
4. Change it back to the original value.
5. Click "Check Pending Changes" to see hasPendingChanges() output.
   Even though you restored the original value, hasPendingChanges() returns true.
6. Click "Submit Changes" to trigger submitBatch("myGroup").
   Even though the value was restored by you, the model still considers the property changed, causing an unnecessary batch request.

// Create OData V4 model
var oModel = new sap.ui.model.odata.v4.ODataModel({
    serviceUrl: "<serviceUrl>/", // e.g. "/sap/opu/odata4/sap/..."
});

// Simple page with an Input (incl. updateGroup) and buttons to check changes and submit batch
var oPage = new sap.m.Page({
    title: "Pending Changes Demo",
    content: [
        new sap.m.Input("myInput", {
            value: {
                path: "/<entitySet>(<key>)/<property>",
                parameters: {
                    $$updateGroupId: "myGroup"
                }
            }
        }),
        new sap.m.Button({
            text: "Check Pending Changes",
            press: function () {
                console.log("hasPendingChanges:", oModel.hasPendingChanges());
            }
        }),
        new sap.m.Button({
            text: "Submit Changes",
            press: function () {
                oModel.submitBatch("myGroup");
            }
        })
    ]
});