10.1p: Grouped ListGrid executes unexpected Queue-Save on doubleclick on groupingRow

[Blama]

Hi Isomorphic,

please see this sample (v10.1p_2017-10-25 and also 11.1p, change: "height:600, canEdit:true) and prepare the data like in the video.
Now change the population value of two countries to "5000000000" (value too large). Then enter row edit mode again and leave it by double click on a groupingRow. For me, this happens:

• Server error message for 1st edit
• Server error message for 2nd edit
• Edit any row again
• Leave rowEditor via double click on grouping row
• All updates sent as queue (expected: Only currently edited row is sent)

Best regards
Blama

[Isomorphic]

We're not sure what you think is a bug here. This sample doesn't set autoSaveEdits:false, so it will save every outstanding edit, rather than letting edits accumulate across multiple rows.

Is your expectation here that the server error means that the first edited value is discarded? That's also not the case, by design: it tends to completely destroy editing that the end user would prefer to correct in place.

[Blama]

Hi Isomorphic,

then the 2nd update should also try to save all the changes, shouldn't it? Because when you leave the 2nd row, the edit for the 1st one is also outstanding.

Best regards
Blama

[Isomorphic]

It's true that there's a slight inconsistency here, however, this is a use case that's not supposed to happen: the server is returning total failure (unexpected error case) rather than a validation error (expected error case). So we're looking a nuance of how the UI behaves when the server is broken and is already returning cryptic, meaningless errors to the end user. We don't plan to look further at this for now.

[Blama]

Hi Isomorphic,

fine for me. I agree that those server failures should not happen and that the consequence of this issue is very minor.

Best regards
Blama