Bug report

Reproduction of the problem

We noticed this issue on our client application. It is especially prominent on a slower network connection. We have a batch edit Grid (in cell editing). We clicked Add to create a new row, added data to it, double-clicked the Save Changes button, refreshed the page, and noticed we had 2 new entries instead of just 1 in the grid. We are currently using v2025.4.1111.

To make sure that it was not something isolated to our specific version / setup, I went to the Kendo grid demo site (https://demos.telerik.com/kendo-ui/grid/editing ) to try and reproduce. At the time of writing this ticket, the Kendo site used the latest version available, v2026.2.520.

Current behavior

The following steps reproduce the issue reliably.

1. Open the DevTools console
2. Click the Network tab and change the network throttle to be "Fast 4G"
3. Click Add in the Grid
4. Type in the cells
5. Click Save Changes several times rapidly
6. Observed multiple "Create" network calls in the DevTools Network tab
7. Refresh the page to see multiple "test567" entries in the Grid

TicketID: 1715189

Environment

• Kendo/Telerik version: Latest
• jQuery version: All
• Browser: [all]

I realize this has been covered by this workaround in the past, but the need to write extra code for moving the column back to the original position makes this seem a bit "hacky" and most importantly, the user experience of being allowed to drag the column in the first place just to see it jump back seems wrong.

The good news is that the kendoGrid already has a mechanism for preventing the columnReorder event from getting fired in the first place! The bad news is that it only happens for columns that have either of these 2 classes ["k-group-cell, "k-hierarchy-cell"]

My request is to have a configuration option that enforces that same behavior for specific columns as:

1. Add a "reorderable" flag to be set as part of the column configuration (set it to false for those we want to keep in place)

2. This flag will set a class on those columns the same way it works for columns with "k-group-cell" or "k-hierarchy-cell" classes, so the event can be prevented.

There is one important caveat to consider with this approach: Only columns at the front and the back of the grid can be locked in place, so there needs to be validation to prevent having non-reorderable columns among reorderable ones.